From ihse at openjdk.org  Tue Jul  1 06:21:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 06:21:51 GMT
Subject: RFR: 8361013: JMH does not export sufficient modules to benchmark
 ImageReader
In-Reply-To: <xGgBGln25JM3Us34SBVKvnoUs09vDqaDi3mTCduEse0=.91815218-6aea-4b60-a7ee-9d81b15fd1dd@github.com>
References: <xGgBGln25JM3Us34SBVKvnoUs09vDqaDi3mTCduEse0=.91815218-6aea-4b60-a7ee-9d81b15fd1dd@github.com>
Message-ID: <DmFUb0n8YFRT0tq33DNdUS3z-LSzjWxlW6ZsE2qqkqg=.b865ab34-4bc5-45dc-974d-411fe76f78fe@github.com>

On Sun, 29 Jun 2025 22:19:18 GMT, David Beaumont <duke at openjdk.org> wrote:

> Added jimage and jrtfs exports.

> FWIW I think these changes to the makefiles are routine enough at this point that we don't need to involve someone from the build team, but they can be approved by any reviewer.

I agree. Just adding addition `--exports` do not require a build system review. With that said, Skara will label any such changes with the `build` tag, so we will get notified. But you don't have to wait for a review from the build team. If I see such changes, I usually add a "build changes trivially fine" just to acknowledge this, but as I said, it's not really a requirement.

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

PR Comment: https://git.openjdk.org/jdk/pull/26035#issuecomment-3022005628

From ihse at openjdk.org  Tue Jul  1 06:22:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 06:22:46 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v3]
In-Reply-To: <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
Message-ID: <sEy5zJyZZgM7ioMx24RWCIlhFUgt29y0e-UwdPgScV8=.2ba693dc-0ce0-449b-8fdb-7583d465a1a1@github.com>

On Mon, 30 Jun 2025 15:08:25 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Initial benchmark to capture at least some comparative measures of ImageReader performance.
>> 
>> Current results on my laptop:
>> 
>> Benchmark                                         Mode  Cnt   Score    Error  Units
>> NewImageBenchmark.warmCache_CountAllNodes         avgt    5   0.785 ?  0.140  ms/op
>> NewImageBenchmark.coldStart_CountOnly               ss    5  34.051 ? 17.662  ms/op
>> NewImageBenchmark.coldStart_InitAndCount            ss    5  31.006 ?  9.674  ms/op
>> NewImageBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.752 ?  6.873  ms/op
>> 
>> The upcoming changes to ImageReader should show significant improvements to these results.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some tidying up relating to the state objects.

Build change trivially fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26044#pullrequestreview-2973675262

From alanb at openjdk.org  Tue Jul  1 07:28:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 07:28:40 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v3]
In-Reply-To: <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
Message-ID: <M2qvXA4FkPbt7awGXF1OyvFYP30fgDpvqws5Vm7jJwc=.6a1d2fd4-0b56-4b04-be2f-779bdbec35e6@github.com>

On Mon, 30 Jun 2025 15:08:25 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Initial benchmark to capture at least some comparative measures of ImageReader performance.
>> 
>> Current results on my laptop:
>> 
>> Benchmark                                         Mode  Cnt   Score    Error  Units
>> NewImageBenchmark.warmCache_CountAllNodes         avgt    5   0.785 ?  0.140  ms/op
>> NewImageBenchmark.coldStart_CountOnly               ss    5  34.051 ? 17.662  ms/op
>> NewImageBenchmark.coldStart_InitAndCount            ss    5  31.006 ?  9.674  ms/op
>> NewImageBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.752 ?  6.873  ms/op
>> 
>> The upcoming changes to ImageReader should show significant improvements to these results.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some tidying up relating to the state objects.

test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 230:

> 228:     // Created by running "java -verbose:class", throwing away anonymous inner
> 229:     // classes and anything without a reliable name, and grouping by the stated
> 230:     // source. It's not perfect, but it's representative.

I don't think this is maintainable. How useful (or not) is this benchmark if the names of all the internal classes (that will change from release to release) are dropped from this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2176636106

From lucy at openjdk.org  Tue Jul  1 09:52:41 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 1 Jul 2025 09:52:41 GMT
Subject: RFR: 8360791: [ubsan] Adjust signal handling [v2]
In-Reply-To: <IMzu0pj3_0YYbxmGyTD1SESnlcJr-ywkJU7K41hcNdA=.6d668bd3-ec77-4bd5-9086-8aa8fee45e62@github.com>
References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com>
 <IMzu0pj3_0YYbxmGyTD1SESnlcJr-ywkJU7K41hcNdA=.6d668bd3-ec77-4bd5-9086-8aa8fee45e62@github.com>
Message-ID: <7FqJZOWwdy26ixPK6Mz964V91vG1Y1kkiNeKOffw1V0=.8a65fd39-0179-45f3-ab91-1cd5849263fb@github.com>

On Mon, 30 Jun 2025 07:02:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs.
>> However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX).
>> The mentioned tests generate a SIGSEGV.
>> 
>> Some other tests generate a SIGBUS, e.g.
>> 
>> runtime/memory/ReserveMemory.java
>> runtime/memory/ReadFromNoaccessArea.java
>> 
>> and this leads to similar issues with ubsan-enabled binaries.
>> 
>> We should adjust the signal handling with the sanitizer options, how to do this is documented here :
>> https://github.com/google/sanitizers/wiki/SanitizerCommonFlags
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the clang check

LGTM.
I agree: don't exclude things just because there is a vague suspicion.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26015#pullrequestreview-2974602300

From mbaesken at openjdk.org  Tue Jul  1 09:58:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Jul 2025 09:58:50 GMT
Subject: Integrated: 8360791: [ubsan] Adjust signal handling
In-Reply-To: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com>
References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com>
Message-ID: <OwH97aGoBCJ9D1BBZTgM6zSflnFgHxrycySZ7fFCMMY=.0fdb7a3f-3ad2-46c9-a4a3-f489b85dea9b@github.com>

On Fri, 27 Jun 2025 09:30:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs.
> However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX).
> The mentioned tests generate a SIGSEGV.
> 
> Some other tests generate a SIGBUS, e.g.
> 
> runtime/memory/ReserveMemory.java
> runtime/memory/ReadFromNoaccessArea.java
> 
> and this leads to similar issues with ubsan-enabled binaries.
> 
> We should adjust the signal handling with the sanitizer options, how to do this is documented here :
> https://github.com/google/sanitizers/wiki/SanitizerCommonFlags

This pull request has now been integrated.

Changeset: aeca49e4
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aeca49e43fab951c2031895fee32703fb4a19524
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8360791: [ubsan] Adjust signal handling

Reviewed-by: ihse, lucy

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

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

From mbaesken at openjdk.org  Tue Jul  1 09:58:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Jul 2025 09:58:49 GMT
Subject: RFR: 8360791: [ubsan] Adjust signal handling [v2]
In-Reply-To: <IMzu0pj3_0YYbxmGyTD1SESnlcJr-ywkJU7K41hcNdA=.6d668bd3-ec77-4bd5-9086-8aa8fee45e62@github.com>
References: <_xiLynxVHloWK4ImZwxEuZ00xOOnPTIdLWPaIUkR6TM=.f9019726-6709-49dd-a6ea-3a98ab288f5c@github.com>
 <IMzu0pj3_0YYbxmGyTD1SESnlcJr-ywkJU7K41hcNdA=.6d668bd3-ec77-4bd5-9086-8aa8fee45e62@github.com>
Message-ID: <-9sTFThc2fmNldQ10SD2o0Q7su6MityEwdj_oLtE93A=.c3dba2c4-e597-4fd0-81ec-8d52e4ecd689@github.com>

On Mon, 30 Jun 2025 07:02:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> A couple of tests e.g. VendorInfoPluginsTest but also some Hotspot like runtime/ErrorHandling/CreateCoredumpOnCrash.java put (write) to special addresses like 0 to provoke crashs.
>> However this does not work well with ubsan-enabled binaries on the clang based platforms (macOS, AIX).
>> The mentioned tests generate a SIGSEGV.
>> 
>> Some other tests generate a SIGBUS, e.g.
>> 
>> runtime/memory/ReserveMemory.java
>> runtime/memory/ReadFromNoaccessArea.java
>> 
>> and this leads to similar issues with ubsan-enabled binaries.
>> 
>> We should adjust the signal handling with the sanitizer options, how to do this is documented here :
>> https://github.com/google/sanitizers/wiki/SanitizerCommonFlags
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the clang check

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26015#issuecomment-3023099250

From ihse at openjdk.org  Tue Jul  1 12:08:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 12:08:23 GMT
Subject: RFR: 8361142: Improve custom hooks for makefiles
Message-ID: <91cuhK8a2VHENkKujTT5Q7CYxYjnK8qV3jULeLXi9jU=.d12fe818-ca41-4448-8a8f-120c60a219d7@github.com>

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

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

Commit messages:
 - Missed hook for cleaning
 - Turns out these were needed after all...
 - 8361142: Improve custom hooks for makefiles

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

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

From ihse at openjdk.org  Tue Jul  1 13:24:41 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 13:24:41 GMT
Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class
 file version
In-Reply-To: <zBi4B-iJTA87Sg2NI5jhElh0BpVNtV7cEPOkQM9LJ-E=.9ced6224-7254-429c-b4f4-1eebd2f0de57@github.com>
References: <R0hJ349y-7LQd-n5h4qNo1Q3XM8wY5853YpwIAsVXpQ=.24cb515f-3277-4708-b05f-7ef60c188b07@github.com>
 <OIu1fg6FTKDl_Hv2YU_oNrzRfSYns6DCkOHZjsaRd-w=.15a69d94-88d9-4993-b9c4-eb32cf37117a@github.com>
 <zBi4B-iJTA87Sg2NI5jhElh0BpVNtV7cEPOkQM9LJ-E=.9ced6224-7254-429c-b4f4-1eebd2f0de57@github.com>
Message-ID: <zNabyTN96DxRz0Bzp5oobw4T9vYdA17Mz8wbDcwXwtc=.591eae5e-f77f-44b3-afb2-51b0604765d5@github.com>

On Mon, 2 Jun 2025 17:21:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I don't think this is a good way. We should not call to shell to make calculations in the makefiles; if that were needed, it should be done in configure. However, we are already doing this, or at least something very similar. Have a look at line 398 in boot-jdk.m4. We set up `OLDEST_BOOT_JDK` as the oldest JDK from the list in version-numbers.conf. 
>> 
>> That should, I think, match your expectation of N-1. There is always a bit uncertainty how you want these things to be handled around the version rollover, and I'm not sure about your use case in those situations. But in general, the oldest boot JDK will match the version number actually used in the build as the boot JDK, that is, N-1.
>> 
>> Now, OLDEST_BOOT_JDK is not exported to make. But that is however:
>> 
>> BOOT_JDK_SOURCETARGET="-source $OLDEST_BOOT_JDK -target $OLDEST_BOOT_JDK -Xlint:-options"
>> 
>> which is almost, but not exactly, what you were planning to add. The added `-Xlint:-options` is harmless afaict, and I think was likely added at some point due to option mismatch between N and N-1 javac lint support, so I think it would make sense for you to use it as well.
>> 
>> So, in essense, my suggestion boils down to that you should only add `$(BOOT_JDK_SOURCETARGET)` to your command line.
>
>> I don't think this is a good way. We should not call to shell to make calculations in the makefiles; if that were needed, it should be done in configure. However, we are already doing this, or at least something very similar. Have a look at line 398 in boot-jdk.m4. We set up `OLDEST_BOOT_JDK` as the oldest JDK from the list in version-numbers.conf.
>> 
>> That should, I think, match your expectation of N-1. There is always a bit uncertainty how you want these things to be handled around the version rollover, and I'm not sure about your use case in those situations. But in general, the oldest boot JDK will match the version number actually used in the build as the boot JDK, that is, N-1.
>> 
>> Now, OLDEST_BOOT_JDK is not exported to make. But that is however:
>> 
>> ```
>> BOOT_JDK_SOURCETARGET="-source $OLDEST_BOOT_JDK -target $OLDEST_BOOT_JDK -Xlint:-options"
>> ```
>> 
>> which is almost, but not exactly, what you were planning to add. The added `-Xlint:-options` is harmless afaict, and I think was likely added at some point due to option mismatch between N and N-1 javac lint support, so I think it would make sense for you to use it as well.
>> 
>> So, in essense, my suggestion boils down to that you should only add `$(BOOT_JDK_SOURCETARGET)` to your command line.
> 
> I don't know the particulars here, but using
> 
> `javac -source $OLD -target $OLD ..."
> 
> is _almost_ never more appropriate than using
> 
> `javac --release $OLD ..."
> 
> The `options` warning would be noting the possible use of `--release`.

@jddarcy I tried replacing the `-source/-target` with `--release` for the Boot JDK overall. However, I get this kind of errors:


error: exporting a package from system module java.base is not allowed with --release


I assume this is why we have still been using  `-source/-target`. But maybe we should move to use `--release` instead, and figure out and fix this issue in a different way?

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

PR Comment: https://git.openjdk.org/jdk/pull/25494#issuecomment-3024001740

From ihse at openjdk.org  Tue Jul  1 14:04:50 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 14:04:50 GMT
Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class
 file version [v2]
In-Reply-To: <fRD46zX3X5dSrMSp4bD-LEKQ-OIBid54IR-sBgiJg9c=.9f55038a-cdb2-439e-b95d-eeef814b1222@github.com>
References: <R0hJ349y-7LQd-n5h4qNo1Q3XM8wY5853YpwIAsVXpQ=.24cb515f-3277-4708-b05f-7ef60c188b07@github.com>
 <fRD46zX3X5dSrMSp4bD-LEKQ-OIBid54IR-sBgiJg9c=.9f55038a-cdb2-439e-b95d-eeef814b1222@github.com>
Message-ID: <lmIQQUd8Rh1s_Ji0GKbYSqMDQZeRCQp3ZwpD6Fz5HKc=.a63d90a5-2fe5-4827-9879-ba7fa172a803@github.com>

On Mon, 2 Jun 2025 17:00:32 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> There are plans to have libgraal be built for JDK master using a version of Native Image running on a JDK one version behind the current JDK. This Native Image execution needs to be able to load the JVMCI classes. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of the current JDK.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use BOOT_JDK_SOURCETARGET instead

For another compilation, I got:

error: option --system cannot be used together with --release


I guess that even if the rule "-source/-target is almost never more appropriate than --release" applies to Java developers at large, building the JDK might be that small corner case where the "almost" actually applies.

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

PR Comment: https://git.openjdk.org/jdk/pull/25494#issuecomment-3024161108

From duke at openjdk.org  Tue Jul  1 14:18:20 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 1 Jul 2025 14:18:20 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support
Message-ID: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>

Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.

This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.

### Preview Mode

In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.

Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.

Below is a summary of the main changes for mainline JDK to better support preview mode later:

### 1: Improved encapsulation for preview mode

The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.

As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).

### 2. Simplification of directory child node handling

The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomplete" and requires users of the API to understand this and potentially "complete" these nodes by calling back into the `ImageReader` API.

This approach is an attempt to provide lazy node creation (which is a necessary trait since there are ~31,000 nodes in a typical jimage hierarchy) but isn't actually necessary since a child node has no "get parent" functionality and simply not creating parent nodes at the point is functionally equivalent.

The partially complete directory nodes also pose an issue for preview mode support, making it more complex to reason about where and when preview child nodes should be applied.

This PR simplifies directory node handling in two ways:
1. Directory nodes are either empty (incomplete) or have all child nodes present.
2. Directory nodes no longer have an API to return their (possibly incomplete) child nodes to users.

This results in simpler to reason about code for directory management and simpler changes later to support preview mode. Removing the on-demand parent directory creation and the partial child list management also has a noticeable performance improvement (based on the new `ImageReaderBenchmark` in pr/26044).

### 3. More comments and code assertions

Since `ImageReader` is a critical bit of internal tooling for OpenJDK, I made sure to add significant comments explaining the behaviour, as well as adding many new in-code assert statements. The version of `ImageReader` in this PR is 70 lines shorter than the current version, but if you account for new comments, it's really a reduction of almost 40% (640 -> 400 lines of code) and has over 200 more comment lines.

### 4. New tests

I added a new unit test for `ImageReader` since, until now, its API was not really being tested directly. These tests are useful now, but will really help when preview mode is added in Valhalla, since then there will need to be significant edge-case testing. I'm happy to improve or change tests in this PR, but they definitely cover the main cases.

### 5. Adding TODO comments for review discussion.

There are obviously some open questions about the exact design of the APIs, and some questions around behaviour. To make reviewing easier, I've added inline TODOs which are there to illicit feedback. I will account for an remove all of these before the PR is integrated, but I want reviewers to read and comment on them (even if there is no change expected).

### Performance Improvements

On my laptop (not objectively interesting, but good for comparison) I am seeing a significant performance improvement over all benchmarks and a reduction in timing variability. These benchmarks are awkward because of the need to test things in a "cold start" state, so timings will have larger variability than expected, but the performance improvements are consistent and non trivial:

Run with `make test TEST="micro:jdk.internal.jrtfs.ImageReaderBenchmark"` using the benchmark currently being added in `pr/26044`:

Current version:

Benchmark                                            Mode  Cnt   Score    Error  Units
ImageReaderBenchmark.warmCache_CountAllNodes         avgt    5   0.784 ?  0.023  ms/op
ImageReaderBenchmark.coldStart_CountOnly               ss    5  37.910 ? 28.554  ms/op
ImageReaderBenchmark.coldStart_InitAndCount            ss    5  37.471 ? 18.775  ms/op
ImageReaderBenchmark.coldStart_LoadJavacInitClasses    ss    5   4.279 ?  7.959  ms/op


This PR:

Benchmark                                            Mode  Cnt   Score   Error  Units
ImageReaderBenchmark.warmCache_CountAllNodes         avgt   10   0.880 ? 0.086  ms/op
ImageReaderBenchmark.coldStart_CountOnly               ss   10  14.303 ? 3.975  ms/op
ImageReaderBenchmark.coldStart_InitAndCount            ss   10  14.032 ? 3.068  ms/op
ImageReaderBenchmark.coldStart_LoadJavacInitClasses    ss   10   2.530 ? 0.348  ms/op


Shows a >2.5x speedup for traversing all nodes in a "cold start" state, and ~1.7x speedup for loading the core set of classes needed to start javac.

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

Depends on: https://git.openjdk.org/jdk/pull/26044

Commit messages:
 - Integrating with ImageReaderBenchmark.
 - Merge branch 'master' into jdk_8355953_reader/squashed
 - undo dependent changes
 - syncing to main branch
 - Newline at EOF.
 - Pretty much ready for review now.
 - WIP - more tests needed.
 - Reapply diffs.

Changes: https://git.openjdk.org/jdk/pull/26054/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360037
  Stats: 2217 lines in 11 files changed: 1613 ins; 342 del; 262 mod
  Patch: https://git.openjdk.org/jdk/pull/26054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26054/head:pull/26054

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

From duke at openjdk.org  Tue Jul  1 14:18:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 1 Jul 2025 14:18:21 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <9xh9VZuuTCyFomE_TV9usc_bVDSPz6ssX5HDmj-hhSU=.18a3192c-57b1-4920-b97b-4cfd37c6fea6@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> wrote:

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

Anything marked "TODO" is for discussion during the coming review. I don't intend to leave any of these in the code after, but they raise specific issues I'd like address.

With these pre-preview comments, I think this is finally ready for review.

make/test/BuildMicrobenchmark.gmk line 1:

> 1: #

Ignore this file, it's part of the PR to add the benchmark. I'll merge and sort everything out once that's in.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 1:

> 1: /*

I think that this class is best reviewed as if it were a new implementation, rather than trying to reason about the specific changes between the versions. Hopefully the comments will make the design clear and the reduced complexity/lines-of-code will help it be understood in a more stand-alone way.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 95:

> 93:     }
> 94: 
> 95:     // directory management interface

A large number of the methods below were either:
1. Unused or effectively no-ops.
2. Breaking encapsulation and leaking underlying types such as `ImageLocation` (not a big problem now, but prevents cleanly implementing the preview mode logic for Valhalla).

The new API has essentially 3 top level methods here:
1. findNode()
2. getResource(Node)
3. getResourceBuffer(Node)

Any navigation of the node hierarchy is done via `getChildNames()` and unlike now, no user can obtain a reference to an "incomplete" node.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 157:

> 155:     }
> 156: 
> 157:     /**

This method and the `getResourceBuffer()` method below are, I think, only called in one place and could, in theory, be factored out of this class altogether.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 255:

> 253:                 if (openers.isEmpty()) {
> 254:                     close();
> 255:                     // TODO (review note): Should this be synchronized by "this" ??

I genuinely this this might be an existing issue.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 601:

> 599:         }
> 600: 
> 601:         /**

Most of these were either never called or no longer needed in the new implementation.

src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 122:

> 120: 
> 121:         @Override
> 122:         public List<Node> getChildren() {

ExplodedImage makes a custom subclass of Node to "fake" the ImageReader behaviour. While this will need to change for preview mode, for now it's enough to just modify the one affected API.

src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributes.java line 52:

> 50:     @Override
> 51:     public FileTime creationTime() {
> 52:         return node.creationTime();

There's no benefit to having all these one-line getter methods duplicated in `ImageReader` since it already provides the file attributes object directly.

src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java line 228:

> 226:         }
> 227:         if (filter == null) {
> 228:             return node.getChildren()

Same logic, just based on the child names instead of the nodes.

src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 61:

> 59:             // open a .jimage and build directory structure
> 60:             final ImageReader image = ImageReader.open(moduleImageFile);
> 61:             image.getRootDirectory();

This method no longer serves any purpose (it used to initialize the root directory entries, but it's not needed now.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 224:

> 222:         ImageReader reader = SystemImage.reader();
> 223:         for (String mn : reader.getModuleNames()) {
> 224:             ImageLocation loc = reader.findLocation(mn, "module-info.class");

It is unsafe to let users see the underlying `ImageLocation` for a resource in preview mode, so this code had to be migrated to using a `Node` based view of the data. This is probably the most complex change not part of `ImageReader` itself.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 509:

> 507:                     if (node.isDirectory()) {
> 508:                         // build node
> 509:                         ImageReader.Node dir = SystemImage.reader().findNode(name);

This is an example of the fragility of the current "partially complete directory" behaviour. The `node` variable is exactly the same instance as the `dir` variable, and the call to `findNode()` serves only to ensure the directory is "complete" before use. In the new API only the name is available, so `findNode()` *must* be called, ensuring there's no risk of accidentally using an incomplete directory node.

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 78:

> 76: 
> 77:     @Test
> 78:     public void testModuleDirectories() throws IOException {

I could make these more data driven (i.e. parametrized) if people want.

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 217:

> 215: 
> 216:     /// Loads and performs actions on classes stored in a given `ImageReader`.
> 217:     private static class ImageClassLoader extends ClassLoader {

Loading and running class bytes to get a `toString()` value will be super important in the preview mode tests to prove that the correct class bytes were used.

test/jdk/jdk/internal/jimage/JImageReadTest.java line 28:

> 26:  * @summary Unit test for libjimage JIMAGE_Open/Read/Close
> 27:  * @modules java.base/jdk.internal.jimage
> 28:  * @run testng/othervm JImageReadTest

Looking back, I don't recall exactly why this was needed. I will see if it's still necessary, but I think it was.

test/jdk/tools/jimage/ImageReaderDuplicateChildNodesTest.java line 1:

> 1: /*

Just uses child names rather than nodes.

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

PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-2973065956
PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-2975530216
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177654333
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177702506
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2176142533
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177705221
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177707657
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177710965
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177658457
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177660750
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177664240
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177671307
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177676879
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177687414
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177691003
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177692842
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177694731
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177697691

From ihse at openjdk.org  Tue Jul  1 14:21:43 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 14:21:43 GMT
Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing
 executables [v3]
In-Reply-To: <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
Message-ID: <ml1xO8DEABmZgQreHjBi3BQWf0AD2BbQk6yX84j1tLs=.3d6d8b1c-e585-4d6d-a09f-6e21244c1b48@github.com>

On Fri, 27 Jun 2025 16:15:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

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

Any reviewers on this?

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

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

From alanb at openjdk.org  Tue Jul  1 14:35:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 14:35:45 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <QPSnXfmDTCKVY47Oh3GplxNEWrpJdvuwXKxz9lvxKSY=.8e5f77ea-1055-4830-9003-cce673330897@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> wrote:

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 62:

> 60: import jdk.internal.module.ModuleHashes.HashSupplier;
> 61: 
> 62: import static java.util.Objects.requireNonNull;

The existing Objects.requireNonNull are okay, no need to change them all as it is nothing to do with the changes.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 251:

> 249:     }
> 250: 
> 251:     private static Stream<ModuleInfo.Attributes> getModuleAttributes() {

Can you rename this to allModuleAttributes and add a method description to match the other methods.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 257:

> 255:                 .getChildNames()
> 256:                 .map(mn -> getNode(reader, mn + "/module-info.class"))
> 257:                 // This fails with ISE if the node isn't a resource (corrupt JImage).

Can you drop this comment and check getNode to thrown an Error (ISE isn't right when we have a broken image).

test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 60:

> 58: @OutputTimeUnit(TimeUnit.MILLISECONDS)
> 59: @Fork(value = 1, jvmArgs = {"--add-exports", "java.base/jdk.internal.jimage=ALL-UNNAMED"})
> 60: public class ImageReaderBenchmark {

This is the benchmark from the other PR, did you mean to include it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177761299
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177768203
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177772042
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177762265

From duke at openjdk.org  Tue Jul  1 14:40:44 2025
From: duke at openjdk.org (ExE Boss)
Date: Tue, 1 Jul 2025 14:40:44 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <wWmD8znj-bwA46ccmxwzDfdHIjLb0Ls3irrN6-o5Scg=.ffc3e9f3-fdc8-4802-b0df-e99d168e6f25@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> wrote:

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 207:

> 205:             this.nodes = new HashMap<>();
> 206:             // TODO (review note): These should exist under all circumstances, but there's
> 207:             //  probably a more robust way of getting it these offsets.

Suggestion:

            //  probably a more robust way of getting these offsets.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 211:

> 209:             this.packagesStringOffset = findLocation("/packages/java.lang").getModuleOffset();
> 210: 
> 211:             // Node creation is very lazy, se can just make the top-level directories

Typo:
Suggestion:

            // Node creation is very lazy, so can just make the top-level directories

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 544:

> 542: 
> 543:         // A node is completed when all its direct children have been built. As
> 544:         // such, non-directory nodes are always complete.

I?think this?might flow?better:
Suggestion:

        // A node is completed when all its direct children have been built.
        // As such, non-directory nodes are always complete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177769091
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177768332
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177779216

From alanb at openjdk.org  Tue Jul  1 14:40:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 14:40:45 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <CdlBFucDBOCgehmRdZSlhW14zhZ4VdLQ8kU3ecHXqpI=.a3a94675-f4c4-4614-b665-7466f3d31345@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> wrote:

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 456:

> 454:             Optional<ImageReader.Node> node = Optional.ofNullable(reader.findNode(nodeName));
> 455:             if (node.isPresent() && !node.get().isResource()) {
> 456:                 throw new IllegalStateException("Not a resource node: " + node.get());

The IllegalStateException is problematic here, maybe you mean to add an assert?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177784419

From duke at openjdk.org  Tue Jul  1 15:09:12 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 1 Jul 2025 15:09:12 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
Message-ID: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>

Hi, please consider the following changes:

this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 

The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 

Tested in tiers 1-3 and GHA.

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

Commit messages:
 - 8320353: Fixed comment
 - 8320353: Fixed whitespace error
 - 8320353:  Fiixed build problem
 - 8320353: Added debug only case
 - 8320353: More work
 - 8320353: More work
 - 8320353: Reenabled stringop-overflow warning for linux zero/fastdebug

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

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

From duke at openjdk.org  Tue Jul  1 16:52:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 1 Jul 2025 16:52:40 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v3]
In-Reply-To: <M2qvXA4FkPbt7awGXF1OyvFYP30fgDpvqws5Vm7jJwc=.6a1d2fd4-0b56-4b04-be2f-779bdbec35e6@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
 <M2qvXA4FkPbt7awGXF1OyvFYP30fgDpvqws5Vm7jJwc=.6a1d2fd4-0b56-4b04-be2f-779bdbec35e6@github.com>
Message-ID: <E4dW0zQJNkVozaAP9rjlBDv-wTEtRKMl0OotVJY-9Tg=.d96625fd-17be-4418-96ad-6de5746ea9b7@github.com>

On Tue, 1 Jul 2025 07:25:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some tidying up relating to the state objects.
>
> test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 230:
> 
>> 228:     // Created by running "java -verbose:class", throwing away anonymous inner
>> 229:     // classes and anything without a reliable name, and grouping by the stated
>> 230:     // source. It's not perfect, but it's representative.
> 
> I don't think this is maintainable. How useful (or not) is this benchmark if the names of all the internal classes (that will change from release to release) are dropped from this?

Debatable. It's obviously going to scale any results somewhat based on the size of the resources and number of classes. It's kind nice to see "this change removes at least N micro/milli seconds of time spent" since that's a minimum set of classes we expect to always be needed, so any time saved is a lower bound.

I'd say maybe leave it as is for now with a note saying "if this keeps breaking, make the list less fragile".
I'm also assuming this is only run manually, and not a part of any CI pipeline ... so please let me know if I'm wrong about that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2178080151

From duke at openjdk.org  Tue Jul  1 17:02:27 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 1 Jul 2025 17:02:27 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
Message-ID: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>

> Initial benchmark to capture at least some comparative measures of ImageReader performance.
> 
> Current results on my laptop:
> 
> Benchmark                                         Mode  Cnt   Score    Error  Units
> NewImageBenchmark.warmCache_CountAllNodes         avgt    5   0.785 ?  0.140  ms/op
> NewImageBenchmark.coldStart_CountOnly               ss    5  34.051 ? 17.662  ms/op
> NewImageBenchmark.coldStart_InitAndCount            ss    5  31.006 ?  9.674  ms/op
> NewImageBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.752 ?  6.873  ms/op
> 
> The upcoming changes to ImageReader should show significant improvements to these results.

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

  Adding comment about maintainability.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26044/files
  - new: https://git.openjdk.org/jdk/pull/26044/files/089b68e2..965abec0

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

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

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

From ihse at openjdk.org  Tue Jul  1 17:31:49 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 17:31:49 GMT
Subject: RFR: 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK
 version
Message-ID: <2CLx0WU6ZAmW7ewzkvL_Lq6ELqc_AvibM9bWZjc8OcY=.86e6519f-3153-45f3-89cf-df30c8a1de29@github.com>

>From the bug description:

There are plans to build libgraal in JDK master using a version of Native Image running on a JDK one version behind JDK master. This Native Image execution needs to be able to load the JVMCI classes as they are built into the libgraal image. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of JDK master. 

This PR is basically the same change as published by Doug in https://github.com/openjdk/jdk/pull/25494, but it contains some cleanup and adds and uses the `TARGET_RELEASE` argument that Doug correctly realized was needed.

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

Commit messages:
 - 8357979: Compile jdk.internal.vm.ci targeting the Boot JDK version

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

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

From rriggs at openjdk.org  Tue Jul  1 18:57:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Jul 2025 18:57:44 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support
In-Reply-To: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <nnLiULvlgT9T3NE_bVbt1wOrepPdbNtHfy20P5UtPLE=.8c7c120e-fb4e-49c8-8c39-80506f3b8980@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> wrote:

> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
> 
> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
> 
> ### Preview Mode
> 
> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
> 
> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
> 
> Below is a summary of the main changes for mainline JDK to better support preview mode later:
> 
> ### 1: Improved encapsulation for preview mode
> 
> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
> 
> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
> 
> ### 2. Simplification of directory child node handling
> 
> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple...

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 555:

> 553: 
> 554:         /**
> 555:          * Returns the JRY file system compatible name of this node (e.g.

Typo:  "JRY"

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 292:

> 290:         @Override
> 291:         public Optional<ModuleReference> find(String name) {
> 292:             requireNonNull(name);

Personal preference is avoid static imports making the code readable by retaining the "Objects." qualifier otherwise the non-local method call appears out of thin air.  YMMV.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178300589
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178311050

From rriggs at openjdk.org  Tue Jul  1 18:57:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Jul 2025 18:57:45 GMT
Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla
 support
In-Reply-To: <9xh9VZuuTCyFomE_TV9usc_bVDSPz6ssX5HDmj-hhSU=.18a3192c-57b1-4920-b97b-4cfd37c6fea6@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <9xh9VZuuTCyFomE_TV9usc_bVDSPz6ssX5HDmj-hhSU=.18a3192c-57b1-4920-b97b-4cfd37c6fea6@github.com>
Message-ID: <7jq-fF6TKn2LVG7na2cKpZ_uR-c-bSZe1xhqt3vaXa4=.397585d5-c923-42de-9431-8a23645df224@github.com>

On Tue, 1 Jul 2025 14:02:11 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name `/modules/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re...
>
> test/jdk/jdk/internal/jimage/ImageReaderTest.java line 78:
> 
>> 76: 
>> 77:     @Test
>> 78:     public void testModuleDirectories() throws IOException {
> 
> I could make these more data driven (i.e. parametrized) if people want.

yes, please, it will make failures easier to identity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178321323

From ihse at openjdk.org  Tue Jul  1 19:04:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Jul 2025 19:04:37 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <bxWyyE5VCVY0EhzEwu3fgOwoK1g1eH-1ar3VEE2RbHw=.30e71e59-041e-4280-8b11-ce40bf154990@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Build changes look good. Someone else will have to review the hotspot changes.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2976656855

From bpb at openjdk.org  Tue Jul  1 23:26:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Jul 2025 23:26:42 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v15]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <ufWpflFhdrPm4cpC-J2_5GYBXqeZoNnOd7NWZMLCc5U=.e2abe1f8-1f0c-4e54-8fbc-9c493cd99887@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - ... and 5 more: https://git.openjdk.org/jdk/compare/9d518b32...ffa3c469

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=14
  Stats: 1539 lines in 93 files changed: 774 ins; 668 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From dholmes at openjdk.org  Wed Jul  2 06:57:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Jul 2025 06:57:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <LIm3kaxNVCwLe6hk7kwoQ8yoiL9EJOiqI3c0U7GSY1s=.3088b118-a78c-47f1-9d84-97b3ac823cc8@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Sorry but I really dislike seeing this compiler-specific pollution in shared code. It is even worse that you have to put it in two places (what is so special about the jvmci code to require this?) just because gcc is "too dumb" keep track of things.

Also IIUC from JBS the problem was only seen building Zero, so maybe we can do something there that is Zero specific?

Sorry.

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

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2977963403

From dnsimon at openjdk.org  Wed Jul  2 08:58:41 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 2 Jul 2025 08:58:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <wMHIciMZ4QYUToxmNokc5_kGX8T_fnwXxmbHlQXt7Qg=.d0cb5bfa-64d4-42b0-b76d-6b5bd81a2956@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 929:

> 927:   if (thread == nullptr) {
> 928:     // This is to prevent --stringop-overflow warning from GCC on linux/fastdebug.
> 929:     // GCC does believe that JavaThread::current() can return nullptr,

`does believe` -> `believes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2179510064

From jwaters at openjdk.org  Wed Jul  2 09:07:44 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Jul 2025 09:07:44 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <T6noB03P0f3RK2RfhSkBqKzxwv8Nvgilrp-8KUPfkNo=.1398d88c-5e1a-4a17-84f1-7e98d9875eaf@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

src/hotspot/share/runtime/javaThread.hpp line 1070:

> 1068:   // Returns the running thread as a JavaThread
> 1069:   static JavaThread* current() {
> 1070:     auto result = JavaThread::cast(Thread::current());

Why auto when the type is known?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2179528150

From jwaters at openjdk.org  Wed Jul  2 09:12:40 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 2 Jul 2025 09:12:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <0_bgDyCHArbkXPSDNQdNWLbrhY2AOJT_BjFTMD38tuY=.9ca01026-bf7e-4d59-8326-d5c4537acc17@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

A less messy solution could be to use PRAGMA_STRINGOP_OVERFLOW_IGNORED instead. The conditionals for the PRAGMA IGNORED macros are already all handled for you, so there's no need to put conditionalizations at the use sites. As an example, simply do the following:


PRAGMA_DIAG_PUSH
PRAGMA_STRINGOP_OVERFLOW_IGNORED
// Problem code here
PRAGMA_DIAG_POP


The first 2 macros are placed directly in front of the problem code, and the last goes behind.

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3027075027

From kbarrett at openjdk.org  Wed Jul  2 14:01:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Jul 2025 14:01:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 926:

> 924: JVMCI::CodeInstallResult CodeInstaller::initialize_buffer(JVMCIObject compiled_code, CodeBuffer& buffer, HotSpotCompiledCodeStream* stream, u1 code_flags, JVMCI_TRAPS) {
> 925:   JavaThread* thread = stream->thread();
> 926: #if defined(__GNUC__) && !defined(__clang__) && !defined(PRODUCT)

Note that `!PRODUCT` does not imply `ASSERT`. There is also the "optimized" build type, which
defines neither `PRODUCT` nor `ASSERT`. I have no idea whether the false-positive gcc warnings
occur in that build configuration. If so, then my suggestion of using an assertion to give the compiler
the clue it needs won't work. But I'm guessing that isn't a problem, in which case the macro check
should be `defined(ASSERT)`.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 936:

> 934:     __builtin_unreachable();
> 935:   }
> 936: #endif

I think this could be replaced with asserting non-null.  A failed assert calls a noreturn reporting
function.

src/hotspot/share/runtime/javaThread.hpp line 1079:

> 1077:   }
> 1078: #endif
> 1079:     return result;

Similarly here, I think this could be replaced with asserting non-null.

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

PR Review: https://git.openjdk.org/jdk/pull/26067#pullrequestreview-2979254552
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180140733
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180123147
PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2180120768

From naoto at openjdk.org  Wed Jul  2 16:25:44 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Jul 2025 16:25:44 GMT
Subject: Withdrawn: 8360774: Use text representation of normalization data
 files
In-Reply-To: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
References: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
Message-ID: <qwMi_YD5Yow-pNEOATyrNKv_ANutIt16RfCk7_AXN3Q=.2078aed1-5a95-4587-ac45-b221019bd0ea@github.com>

On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process

This pull request has been closed without being integrated.

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

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

From jkratochvil at openjdk.org  Wed Jul  2 17:20:48 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 2 Jul 2025 17:20:48 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
Message-ID: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>

https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
[build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk21u-dev/jdk21u-dev/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
Error: sh][ERROR] wget exited with exit code 4
Error: Process completed with exit code 1.

It is enough to make an empty commit "retry CI" and push it to re-run the Github CI.
It happened for me twice:
https://github.com/openjdk/jdk21u-dev/pull/1663#event-18416642257
-> (I did not save the log, unaware how to access it now)
https://github.com/openjdk/jdk21u-dev/pull/1664#commits-pushed-c00e2ab
-> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689

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

Commit messages:
 - 8361288: Fix build of JTReg: wget exited with exit code 4

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

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

From kbarrett at openjdk.org  Thu Jul  3 01:32:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 01:32:53 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
 <LLpd1-mLP3Q6EoLyOgM65uXPooSxUuw51szHOjR6bF0=.8a18dc2a-6b9a-49a6-b3f9-fad520377a7c@github.com>
Message-ID: <fN-YSbHIJgK0sJ_O9fEtRgXSPyzrVT10D7_Cds5zvn0=.9a06b83c-984c-4f87-bce8-46639c458e4f@github.com>

On Wed, 2 Jul 2025 13:51:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
>> 
>> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
>> 
>> Tested in tiers 1-3 and GHA.
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 936:
> 
>> 934:     __builtin_unreachable();
>> 935:   }
>> 936: #endif
> 
> I think this could be replaced with asserting non-null.  A failed assert calls a noreturn reporting
> function.

Although I wonder why the assert in Thread::current() isn't sufficient? Maybe non-null info isn't
propagating through the cast to JavaThread?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2181311538

From kbarrett at openjdk.org  Thu Jul  3 01:52:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 01:52:41 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <SPURRbg_QDlnGackOfs8p6LKFH3f9AdHgRZu_s_bUkA=.183c6e9d-48be-4bf4-8f85-9923da9da039@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

make/hotspot/lib/CompileJvm.gmk line 199:

> 197:     DISABLED_WARNINGS_gcc_macroAssembler_ppc_sha.cpp := unused-const-variable, \
> 198:     DISABLED_WARNINGS_gcc_postaloc.cpp := address, \
> 199:     DISABLED_WARNINGS_gcc_shenandoahLock.cpp := stringop-overflow, \

What about this one in shenandoahLock.cpp?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26067#discussion_r2181357398

From kbarrett at openjdk.org  Thu Jul  3 05:36:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 3 Jul 2025 05:36:42 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

My suggestion of using assertions instead doesn't seem to work, still getting
bogus warnings. This is with gcc14.2 on linux-aarch64, which also uses
__atomic_load. That is mysteriously weird. The noreturn reporting function
should be roughly equivalent to calling an ordinary function with an
"unreachable" following it. But then, this whole issue is mysteriously weird.

But that's okay; I wasn't really all that keen on adding assertions to
suppress bogus compiler warnings anyway.

At this point I think this change should just not be made. It's a compiler
bug. The existing suppression of the warnings is fine with me.

I think what's really needed is for someone to file a gcc bug.  It's too bad
nobody did that when the issue was first noticed.  There's already a bug that
is similar, and might even be the same, even though it involves sanitizers and
ours doesn't:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3030839463

From duke at openjdk.org  Thu Jul  3 07:47:40 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 3 Jul 2025 07:47:40 GMT
Subject: RFR: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
 <M6RgvhXwuZ6Rl3z62kcTVsbRMAlOVGuodqbsKyKHzFo=.bca79592-4adc-4027-88c3-1d70b7f86090@github.com>
Message-ID: <YunUc3j5XRipL9egR5B7dqs0ANTJ6ETSL2udnFcBXDY=.ea2ee97d-caf9-4a06-b02a-f63aebe00f8a@github.com>

On Thu, 3 Jul 2025 05:34:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> My suggestion of using assertions instead doesn't seem to work, still getting bogus warnings. This is with gcc14.2 on linux-aarch64, which also uses __atomic_load. That is mysteriously weird. The noreturn reporting function should be roughly equivalent to calling an ordinary function with an "unreachable" following it. But then, this whole issue is mysteriously weird.
> 
> But that's okay; I wasn't really all that keen on adding assertions to suppress bogus compiler warnings anyway.
> 
> At this point I think this change should just not be made. It's a compiler bug. The existing suppression of the warnings is fine with me.
> 
> I think what's really needed is for someone to file a gcc bug. It's too bad nobody did that when the issue was first noticed. There's already a bug that is similar, and might even be the same, even though it involves sanitizers and ours doesn't: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775

Thanks @kimbarrett, after looking at your findings I agree that it looks like a GCC bug, and therefore we should not do this change. I will try to make the smallest reproducible example and submit a bug report.

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

PR Comment: https://git.openjdk.org/jdk/pull/26067#issuecomment-3031232698

From ihse at openjdk.org  Thu Jul  3 10:21:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Jul 2025 10:21:40 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
In-Reply-To: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
Message-ID: <ssABLvpNGyapgy8zINfDtAe_pwZJs0dF3hdEzdhCgGY=.8488ec82-79d7-433e-b4ec-bb3a32e31b98@github.com>

On Wed, 2 Jul 2025 16:52:39 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
> [build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk21u-dev/jdk21u-dev/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
> Error: sh][ERROR] wget exited with exit code 4
> Error: Process completed with exit code 1.
> 
> It is enough to make an empty commit "retry CI" and push it to re-run the Github CI.
> It happened for me twice:
> https://github.com/openjdk/jdk21u-dev/pull/1663#event-18416642257
> -> (I did not save the log, unaware how to access it now)
> https://github.com/openjdk/jdk21u-dev/pull/1664#commits-pushed-c00e2ab
> -> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689

It's really a bummer that we need to build jtreg each time we run a GHA test. :-(

.github/actions/build-jtreg/action.yml line 59:

> 57:         while ! bash make/build.sh --jdk "$JAVA_HOME_17_X64"; do
> 58:           retry=$[$retry+1]
> 59:           if [ $retry -gt 20 ];then

20 retries seems excessive. There is likely a persistent problem if it retries that many times.

Suggestion:

          if [ $retry -gt 3 ];then

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

PR Comment: https://git.openjdk.org/jdk/pull/26100#issuecomment-3031719129
PR Review Comment: https://git.openjdk.org/jdk/pull/26100#discussion_r2182416593

From jkratochvil at openjdk.org  Thu Jul  3 11:00:28 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 3 Jul 2025 11:00:28 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
 [v2]
In-Reply-To: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
Message-ID: <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>

> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
> [build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk21u-dev/jdk21u-dev/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
> Error: sh][ERROR] wget exited with exit code 4
> Error: Process completed with exit code 1.
> 
> It is enough to make an empty commit "retry CI" and push it to re-run the Github CI.
> It happened for me twice:
> https://github.com/openjdk/jdk21u-dev/pull/1663#event-18416642257
> -> (I did not save the log, unaware how to access it now)
> https://github.com/openjdk/jdk21u-dev/pull/1664#commits-pushed-c00e2ab
> -> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689

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

  retries 20->3
  add a sleep 30

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26100/files
  - new: https://git.openjdk.org/jdk/pull/26100/files/45c41735..be68526a

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

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

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

From jkratochvil at openjdk.org  Thu Jul  3 11:00:29 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 3 Jul 2025 11:00:29 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
 [v2]
In-Reply-To: <ssABLvpNGyapgy8zINfDtAe_pwZJs0dF3hdEzdhCgGY=.8488ec82-79d7-433e-b4ec-bb3a32e31b98@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ssABLvpNGyapgy8zINfDtAe_pwZJs0dF3hdEzdhCgGY=.8488ec82-79d7-433e-b4ec-bb3a32e31b98@github.com>
Message-ID: <Phkwnea9ouVtG3l3BG3ygzjwEzKZXlxYW_Gr8RwVSt8=.8168e50e-1905-43ae-9b52-3bb0dd1f635b@github.com>

On Thu, 3 Jul 2025 10:18:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   retries 20->3
>>   add a sleep 30
>
> .github/actions/build-jtreg/action.yml line 59:
> 
>> 57:         while ! bash make/build.sh --jdk "$JAVA_HOME_17_X64"; do
>> 58:           retry=$[$retry+1]
>> 59:           if [ $retry -gt 20 ];then
> 
> 20 retries seems excessive. There is likely a persistent problem if it retries that many times.
> 
> Suggestion:
> 
>           if [ $retry -gt 3 ];then

Done. I have also added a sleep 30.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26100#discussion_r2182489712

From ihse at openjdk.org  Thu Jul  3 11:01:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Jul 2025 11:01:22 GMT
Subject: RFR: 8361306: jdk.compiler-gendata needs to depend on
 java.base-launchers
Message-ID: <Ypwb4ZKxOf-WZPxp3_ECLpTTwfwlyqNGBo5AX20jlig=.f273a4f0-1072-4022-80ef-85d6b987bf54@github.com>

A recent run in the Oracle CI produced the following:

Creating ct.sym classes
/bin/bash: $WS/build/linux-aarch64-open/jdk/bin/java: No such file or directory
modules/jdk.compiler/Gendata.gmk:72: recipe for target '$WS/build/linux-aarch64-open/support/symbols/ct.sym' failed
make[3]: *** [$WS/build/linux-aarch64-open/support/symbols/ct.sym] Error 127
make[2]: *** [jdk.compiler-gendata] Error 2
make[2]: *** Waiting for unfinished jobs....
make/Main.gmk:136: recipe for target 'jdk.compiler-gendata' failed 


`jdk.compiler/Gendata.gmk` calls `$(BUILD_JAVA_SMALL)`, which is created by java.base-launchers (unless cross-compiling). This dependency is not recorded, and it has just worked due to pure luck since jdk/bin/java is usually produced much earlier in the build process.

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

Commit messages:
 - 8361306: jdk.compiler-gendata needs to depend on java.base-launchers

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

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

From duke at openjdk.org  Thu Jul  3 12:04:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 3 Jul 2025 12:04:44 GMT
Subject: Withdrawn: 8320353: Reenable stringop-overflow warnings
In-Reply-To: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
References: <AWiF73BlsZ3NptMul6doFVw_XDpAyXSyIk5zOtGLrig=.75ff3d22-524e-423b-998a-9a5a7bb5098f@github.com>
Message-ID: <ifHIvUSdpFXevUEdGdw4H2NlTNegBILudXcalRwNBpQ=.7f952342-0bcb-4ba4-be49-6618d4b6755d@github.com>

On Tue, 1 Jul 2025 12:25:04 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> this PR addresses the issue of stringop-overflow warnings produced by GCC. The compiler does think that the thread pointer returned by `JavaThread::current()` can be null, though it cant. The thread pointer ends up being an argument in `__atomic_load`, and the compiler reports the warning related to argument of that method. 
> 
> The patch adds a hint to the compiler by means of `__builtin_unreachable()` intrinsic, which tells the compiler that certain piece of code will never be reached (case of thread pointer being null). This solves the issue. 
> 
> Tested in tiers 1-3 and GHA.

This pull request has been closed without being integrated.

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

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

From shade at openjdk.org  Thu Jul  3 12:41:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Jul 2025 12:41:41 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
 [v2]
In-Reply-To: <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
Message-ID: <fC2gyog4CSP7TrrVg-Uxhnq1vRt-UkC8nmkHTrmwzHE=.d0d11be3-0abc-4a42-9139-1c04e7426d8a@github.com>

On Thu, 3 Jul 2025 11:00:28 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
>> [build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk21u-dev/jdk21u-dev/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
>> Error: sh][ERROR] wget exited with exit code 4
>> Error: Process completed with exit code 1.
>> 
>> It is enough to make an empty commit "retry CI" and push it to re-run the Github CI.
>> It happened for me twice:
>> https://github.com/openjdk/jdk21u-dev/pull/1663#event-18416642257
>> -> (I did not save the log, unaware how to access it now)
>> https://github.com/openjdk/jdk21u-dev/pull/1664#commits-pushed-c00e2ab
>> -> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retries 20->3
>   add a sleep 30

We tried this before: https://bugs.openjdk.org/browse/JDK-8343190 -- and it did not work, so we have backed out. It looked as if the rate limiter basically bans the access for hours, so short retries do not work.

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

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26100#pullrequestreview-2983003303

From shade at openjdk.org  Thu Jul  3 12:41:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Jul 2025 12:41:42 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
In-Reply-To: <ssABLvpNGyapgy8zINfDtAe_pwZJs0dF3hdEzdhCgGY=.8488ec82-79d7-433e-b4ec-bb3a32e31b98@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ssABLvpNGyapgy8zINfDtAe_pwZJs0dF3hdEzdhCgGY=.8488ec82-79d7-433e-b4ec-bb3a32e31b98@github.com>
Message-ID: <4YYMKL3XwB2-GPNyX2lHSbrLN3SUBn5FbLkzBXaKHBE=.76922fd2-ac7a-4b76-a3fa-73c9888d20df@github.com>

On Thu, 3 Jul 2025 10:19:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It's really a bummer that we need to build jtreg each time we run a GHA test. :-(

Not each time, once per PR, then it gets cached :) It is a small consolation, though. It would be better once I have enough mental fortitude to complete [JDK-8343546](https://bugs.openjdk.org/browse/JDK-8343546) -- then jtreg would be cached across different PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/26100#issuecomment-3032117946

From jkratochvil at openjdk.org  Thu Jul  3 13:42:48 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 3 Jul 2025 13:42:48 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
 [v2]
In-Reply-To: <fC2gyog4CSP7TrrVg-Uxhnq1vRt-UkC8nmkHTrmwzHE=.d0d11be3-0abc-4a42-9139-1c04e7426d8a@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
 <fC2gyog4CSP7TrrVg-Uxhnq1vRt-UkC8nmkHTrmwzHE=.d0d11be3-0abc-4a42-9139-1c04e7426d8a@github.com>
Message-ID: <yCNXlMd_6oMgqFhKaTXbr2t81DNTAKb82agLwSZwPOw=.04f55d01-5a5c-46df-9171-b68880794bc6@github.com>

On Thu, 3 Jul 2025 12:37:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It looked as if the rate limiter basically bans the access for hours, so short retries do not work. I see no point in trying it again.

OK so closing this one, it really looks the same.

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

PR Comment: https://git.openjdk.org/jdk/pull/26100#issuecomment-3032320997

From jkratochvil at openjdk.org  Thu Jul  3 13:42:49 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 3 Jul 2025 13:42:49 GMT
Subject: Withdrawn: 8361288: Fix build of JTReg: wget exited with exit code 4
In-Reply-To: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
Message-ID: <nPAL4dscxOQDJi7vMNebSYIXTS3b_ecrTber6PPAZ4M=.06e47c9c-3266-4a47-b306-381728ffa183@github.com>

On Wed, 2 Jul 2025 16:52:39 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
> [build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk21u-dev/jdk21u-dev/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
> Error: sh][ERROR] wget exited with exit code 4
> Error: Process completed with exit code 1.
> 
> It is enough to make an empty commit "retry CI" and push it to re-run the Github CI.
> It happened for me twice:
> https://github.com/openjdk/jdk21u-dev/pull/1663#event-18416642257
> -> (I did not save the log, unaware how to access it now)
> https://github.com/openjdk/jdk21u-dev/pull/1664#commits-pushed-c00e2ab
> -> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689

This pull request has been closed without being integrated.

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

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

From shade at openjdk.org  Thu Jul  3 13:48:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Jul 2025 13:48:40 GMT
Subject: RFR: 8361306: jdk.compiler-gendata needs to depend on
 java.base-launchers
In-Reply-To: <Ypwb4ZKxOf-WZPxp3_ECLpTTwfwlyqNGBo5AX20jlig=.f273a4f0-1072-4022-80ef-85d6b987bf54@github.com>
References: <Ypwb4ZKxOf-WZPxp3_ECLpTTwfwlyqNGBo5AX20jlig=.f273a4f0-1072-4022-80ef-85d6b987bf54@github.com>
Message-ID: <qCvIaXUdwQ9BW3Nz1ERwvNYjWXOQdItrBIpYa_ao6Ig=.55266d0b-69a4-4b35-894a-f88f24bc8ca5@github.com>

On Thu, 3 Jul 2025 10:55:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A recent run in the Oracle CI produced the following:
> 
> Creating ct.sym classes
> /bin/bash: $WS/build/linux-aarch64-open/jdk/bin/java: No such file or directory
> modules/jdk.compiler/Gendata.gmk:72: recipe for target '$WS/build/linux-aarch64-open/support/symbols/ct.sym' failed
> make[3]: *** [$WS/build/linux-aarch64-open/support/symbols/ct.sym] Error 127
> make[2]: *** [jdk.compiler-gendata] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make/Main.gmk:136: recipe for target 'jdk.compiler-gendata' failed 
> 
> 
> `jdk.compiler/Gendata.gmk` calls `$(BUILD_JAVA_SMALL)`, which is created by java.base-launchers (unless cross-compiling). This dependency is not recorded, and it has just worked due to pure luck since jdk/bin/java is usually produced much earlier in the build process.

Looks okay, but I also wonder if `jdk.javadoc-gendata` needs to depend on `java.base-launchers` too? I guess it only needs `bin/javadoc`, and that's why it works?

Alternatively, maybe we make `jdk.compiler-launchers` depend on `java.base-launchers`? IMO sounds reasonable that component-specific launcher depends on the "base" launcher like this.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26113#pullrequestreview-2983266065

From sgehwolf at openjdk.org  Thu Jul  3 13:54:44 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Jul 2025 13:54:44 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
 [v2]
In-Reply-To: <fC2gyog4CSP7TrrVg-Uxhnq1vRt-UkC8nmkHTrmwzHE=.d0d11be3-0abc-4a42-9139-1c04e7426d8a@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
 <fC2gyog4CSP7TrrVg-Uxhnq1vRt-UkC8nmkHTrmwzHE=.d0d11be3-0abc-4a42-9139-1c04e7426d8a@github.com>
Message-ID: <TUeczGuRLgQxMkCxqwsDH_i7OyBWDPqt9PWPNUsUSyY=.350e6a27-0382-4ebd-aec1-a2d6f7162975@github.com>

On Thu, 3 Jul 2025 12:37:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We tried the retries like this before: https://bugs.openjdk.org/browse/JDK-8343190 -- and it did not work, so we have backed out. It looked as if the rate limiter basically bans the access for hours, so short retries do not work. I see no point in trying it again.

Yes. This hits archive.apache.org which has this warning:


Do note that heavy use of this service will result in immediate throttling of your download speeds to either 12 or 6
mbps for the remainder of the day, depending on severity. Continuous abuse (to the tune of more than 40 GB 
downloaded per week) will cause an [automatic ban](https://infra.apache.org/infra-ban.html), so please tune your 
services to this fact.


It's conceivable that GHA runners run into some of those limits.

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

PR Comment: https://git.openjdk.org/jdk/pull/26100#issuecomment-3032363126

From ihse at openjdk.org  Thu Jul  3 14:36:41 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Jul 2025 14:36:41 GMT
Subject: RFR: 8361306: jdk.compiler-gendata needs to depend on
 java.base-launchers
In-Reply-To: <Ypwb4ZKxOf-WZPxp3_ECLpTTwfwlyqNGBo5AX20jlig=.f273a4f0-1072-4022-80ef-85d6b987bf54@github.com>
References: <Ypwb4ZKxOf-WZPxp3_ECLpTTwfwlyqNGBo5AX20jlig=.f273a4f0-1072-4022-80ef-85d6b987bf54@github.com>
Message-ID: <Di-cCuOpanItfHXSEi1pWTAvwA6D4zvFELlk7oLyeYQ=.496ebb6f-34a0-4d3f-aaba-6ac65c337bcb@github.com>

On Thu, 3 Jul 2025 10:55:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A recent run in the Oracle CI produced the following:
> 
> Creating ct.sym classes
> /bin/bash: $WS/build/linux-aarch64-open/jdk/bin/java: No such file or directory
> modules/jdk.compiler/Gendata.gmk:72: recipe for target '$WS/build/linux-aarch64-open/support/symbols/ct.sym' failed
> make[3]: *** [$WS/build/linux-aarch64-open/support/symbols/ct.sym] Error 127
> make[2]: *** [jdk.compiler-gendata] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make/Main.gmk:136: recipe for target 'jdk.compiler-gendata' failed 
> 
> 
> `jdk.compiler/Gendata.gmk` calls `$(BUILD_JAVA_SMALL)`, which is created by java.base-launchers (unless cross-compiling). This dependency is not recorded, and it has just worked due to pure luck since jdk/bin/java is usually produced much earlier in the build process.

I did check jdk.javadoc/Gendata.gmk, and it only relies on the boot JDK. `jdk-compiler-launchers` is for creating `javac`, and it has not much to do with the current situation. We don't need to rely on having created the `java` launcher for that, and it is also the gendata step is performed before building launchers, so even if we put a dependency to the java.base-launcher there, there would still be a missing dependency for the gendata phase.

(The launchers do need libjli, but I am pretty sure this dependency is already covered. They do not need any other launcher, they are all independent.)

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

PR Comment: https://git.openjdk.org/jdk/pull/26113#issuecomment-3032504486

From ihse at openjdk.org  Thu Jul  3 16:06:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Jul 2025 16:06:45 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
 [v2]
In-Reply-To: <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
Message-ID: <-z0tD9_QTa8h4jGagnGB9mtA0d6WlhvE0rXmASN1e8I=.2a9600cd-ed00-4f81-bfe9-104e3d85c47a@github.com>

On Thu, 3 Jul 2025 11:00:28 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
>> [build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk21u-dev/jdk21u-dev/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
>> Error: sh][ERROR] wget exited with exit code 4
>> Error: Process completed with exit code 1.
>> 
>> It is enough to make an empty commit "retry CI" and push it to re-run the Github CI.
>> It happened for me twice:
>> https://github.com/openjdk/jdk21u-dev/pull/1663#event-18416642257
>> -> (I did not save the log, unaware how to access it now)
>> https://github.com/openjdk/jdk21u-dev/pull/1664#commits-pushed-c00e2ab
>> -> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retries 20->3
>   add a sleep 30

I feel we're not being very good net citizens here if we overload the apache infrastructure, regardless of if we get throttled or not... :-( Is there some other cache we can get the stuff we need from instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/26100#issuecomment-3032811186

From sgehwolf at openjdk.org  Thu Jul  3 16:29:44 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Jul 2025 16:29:44 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
 [v2]
In-Reply-To: <-z0tD9_QTa8h4jGagnGB9mtA0d6WlhvE0rXmASN1e8I=.2a9600cd-ed00-4f81-bfe9-104e3d85c47a@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
 <-z0tD9_QTa8h4jGagnGB9mtA0d6WlhvE0rXmASN1e8I=.2a9600cd-ed00-4f81-bfe9-104e3d85c47a@github.com>
Message-ID: <JxPAxjU9HpRWqi_Ra7aiPdaly9p8LqZq9FDGkgylZ7k=.592eb9a8-63e9-473c-908b-0ed671c34ceb@github.com>

On Thu, 3 Jul 2025 16:04:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I feel we're not being very good net citizens here if we overload the apache infrastructure, regardless of if we get throttled or not... :-( Is there some other cache we can get the stuff we need from instead?

I think if we were able to host a copy of ant 1.10.8 (the default version that jtreg uses) somewhere then we could switch to that instead when building jtreg.

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

PR Comment: https://git.openjdk.org/jdk/pull/26100#issuecomment-3032868300

From shade at openjdk.org  Thu Jul  3 18:43:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Jul 2025 18:43:44 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
In-Reply-To: <4YYMKL3XwB2-GPNyX2lHSbrLN3SUBn5FbLkzBXaKHBE=.76922fd2-ac7a-4b76-a3fa-73c9888d20df@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ssABLvpNGyapgy8zINfDtAe_pwZJs0dF3hdEzdhCgGY=.8488ec82-79d7-433e-b4ec-bb3a32e31b98@github.com>
 <4YYMKL3XwB2-GPNyX2lHSbrLN3SUBn5FbLkzBXaKHBE=.76922fd2-ac7a-4b76-a3fa-73c9888d20df@github.com>
Message-ID: <Gmc6kt3CNDtJiD2DxPdZMfxMgMppN5FNQv-nsdcdXzw=.76374691-91ac-4237-a512-b5cffc3c1a1c@github.com>

On Thu, 3 Jul 2025 12:39:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Not each time, once per PR, then it gets cached :) It is a small consolation, though. It would be better once I have enough mental fortitude to complete [JDK-8343546](https://bugs.openjdk.org/browse/JDK-8343546) -- then jtreg would be cached across different PRs.

FWIW, I now have a version that works, but it is somewhat ugly: https://github.com/openjdk/jdk/compare/master...shipilev:JDK-8343546-gha-master-cache :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26100#issuecomment-3033206979

From ihse at openjdk.org  Fri Jul  4 12:21:43 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Jul 2025 12:21:43 GMT
Subject: Integrated: 8361306: jdk.compiler-gendata needs to depend on
 java.base-launchers
In-Reply-To: <Ypwb4ZKxOf-WZPxp3_ECLpTTwfwlyqNGBo5AX20jlig=.f273a4f0-1072-4022-80ef-85d6b987bf54@github.com>
References: <Ypwb4ZKxOf-WZPxp3_ECLpTTwfwlyqNGBo5AX20jlig=.f273a4f0-1072-4022-80ef-85d6b987bf54@github.com>
Message-ID: <BwMQgrViXfJVnjnLFDTUdPr-OU8M8TYWZ2GEiP3GIYQ=.f007d4f8-3690-446d-8070-62eb39d99abc@github.com>

On Thu, 3 Jul 2025 10:55:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A recent run in the Oracle CI produced the following:
> 
> Creating ct.sym classes
> /bin/bash: $WS/build/linux-aarch64-open/jdk/bin/java: No such file or directory
> modules/jdk.compiler/Gendata.gmk:72: recipe for target '$WS/build/linux-aarch64-open/support/symbols/ct.sym' failed
> make[3]: *** [$WS/build/linux-aarch64-open/support/symbols/ct.sym] Error 127
> make[2]: *** [jdk.compiler-gendata] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make/Main.gmk:136: recipe for target 'jdk.compiler-gendata' failed 
> 
> 
> `jdk.compiler/Gendata.gmk` calls `$(BUILD_JAVA_SMALL)`, which is created by java.base-launchers (unless cross-compiling). This dependency is not recorded, and it has just worked due to pure luck since jdk/bin/java is usually produced much earlier in the build process.

This pull request has now been integrated.

Changeset: fba74f79
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fba74f796eeeb42accc60ecab444c3d933b73e70
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361306: jdk.compiler-gendata needs to depend on java.base-launchers

Reviewed-by: shade

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

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

From shade at openjdk.org  Fri Jul  4 13:27:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 4 Jul 2025 13:27:18 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow
Message-ID: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>

In our current GHA workflows, we only run workflows in branches in personal forks. GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches. For our branches, the usual parent is `master`. Since we do not run workflows on `master`, this means every time we create a new branch, GHA would start with logically empty caches for it. Only the next trigger on the same branch would use the caches, saved from the first workflow run.

This means we put additional load on shared infrastructure with pulling JDKs, building jtreg (and pulling its dependencies), bootstrapping sysroots, etc. All these steps also fail intermittently every so often. It also means everyone carries lots of caches around, segregated by branch (look into your https://github.com/<github-name>/caches) only relying on cache cleanups when it starts to hit 10 GB. With 200+ contributors, this is easily 2 TB of cloud space we effectively waste in GHA clouds.

We can make all this more reliable, if we manage to run a master-branch workflow that bootstraps all required dependencies and caches them. These dependencies can then be used by PR branches, as "master" branch is their effective parent. 

This PR introduces the notion of "dry run", which does everything _except_ the actual builds and tests. Therefore, it verifies whether all dependencies are done properly for JDK configure to pass. This is useful in itself for future GHA debugging of dependencies. Workflow can be dispatched with additional "dry run" parameter now.

What makes master-branch caching possible is the second part of the PR that hooks up dry runs to master/stabilization branch pushes. These would make the dry-run workflow run every time you update your personal fork's master/stabilization branch. That dry run would likely finish very quickly if all caches are already in place. It would populate caches in master/stabilization branch in your personal fork, if not. 

The expected net result is that actual PRs that are branched off the personal fork master would be able to use the caches from that branch. (If you want to make this experiment in current GHA, trigger the existing workflow on `master` branch in your fork, it would do roughly the same, but with all builds/tests).

A sample "dry-run" can be seen here: https://github.com/shipilev/jdk/actions/runs/16074619302. The most heavy-weight part is MSYS2 unpacking in Windows builds, and that part is beyond our reach; the relevant GH action maintained by MSYS2 folks is responsible for managing caches for it.

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

Commit messages:
 - Single-script dry run
 - Initial version: dry-run from a separate file

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

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

From shade at openjdk.org  Fri Jul  4 13:27:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 4 Jul 2025 13:27:49 GMT
Subject: RFR: 8361288: Fix build of JTReg: wget exited with exit code 4
 [v2]
In-Reply-To: <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
References: <Z4JNzVY5QX-5MLknUK0mIP36juSH0paaRRvMfJpRfRc=.6ceab9e8-765e-416a-9d48-d403707cc89c@github.com>
 <ZthIWvRqf0DmKfAutS3vzzGb6pjZuN0SBmyQszCQn_8=.d32a9909-b091-4b7d-baba-ad16d9fb1906@github.com>
Message-ID: <kpTwOMG97oTkMrgQu7bhcC4LCcScRnzjsrw7VQJDDps=.d9508249-69df-4fb7-809e-ef4f440e2b3c@github.com>

On Thu, 3 Jul 2025 11:00:28 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
>> [build.sh][INFO] Downloading https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to /home/runner/work/jdk21u-dev/jdk21u-dev/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
>> Error: sh][ERROR] wget exited with exit code 4
>> Error: Process completed with exit code 1.
>> 
>> It is enough to make an empty commit "retry CI" and push it to re-run the Github CI.
>> It happened for me twice:
>> https://github.com/openjdk/jdk21u-dev/pull/1663#event-18416642257
>> -> (I did not save the log, unaware how to access it now)
>> https://github.com/openjdk/jdk21u-dev/pull/1664#commits-pushed-c00e2ab
>> -> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retries 20->3
>   add a sleep 30

> > Not each time, once per PR, then it gets cached :) It is a small consolation, though. It would be better once I have enough mental fortitude to complete [JDK-8343546](https://bugs.openjdk.org/browse/JDK-8343546) -- then jtreg would be cached across different PRs.
> 
> FWIW, I now have a version that works, but it is somewhat ugly: [master...shipilev:JDK-8343546-gha-master-cache](https://github.com/openjdk/jdk/compare/master...shipilev:JDK-8343546-gha-master-cache) :)

Got a much cleaner version here: https://github.com/openjdk/jdk/pull/26134

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

PR Comment: https://git.openjdk.org/jdk/pull/26100#issuecomment-3036278152

From ihse at openjdk.org  Fri Jul  4 14:26:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Jul 2025 14:26:39 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow
In-Reply-To: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
Message-ID: <QheMs1i087lV9bjBO0W0-G24ghXqWyd8xdH0n9lI-NI=.1a849775-5450-4464-844b-c4f896296ddb@github.com>

On Fri, 4 Jul 2025 13:21:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In our current GHA workflows, we only run workflows in branches in personal forks. GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches. For our branches, the usual parent is `master`. Since we do not run workflows on `master`, this means every time we create a new branch, GHA would start with logically empty caches for it. Only the next trigger on the same branch would use the caches, saved from the first workflow run.
> 
> This means we put additional load on shared infrastructure with pulling JDKs, building jtreg (and pulling its dependencies), bootstrapping sysroots, etc. All these steps also fail intermittently every so often. It also means everyone carries lots of caches around, segregated by branch and repo (look into your https://github.com/your-github-name/jdk/actions/caches, for example) only relying on cache cleanups when it starts to hit 10 GB. With hundreds of contributors, this easily wastes terabytes of cloud storage space.
> 
> We can make all this more efficient and reliable, if we manage to run a master-branch workflow that bootstraps all required dependencies and caches them. These dependencies can then be used by PR branches, as "master" branch is their effective parent. 
> 
> This PR introduces the notion of "dry run", which does everything _except_ the actual builds and tests. Therefore, it verifies whether all dependencies are done properly for JDK configure to pass. This is useful in itself for future GHA debugging of dependencies. Workflow can be dispatched with additional "dry run" parameter now.
> 
> What makes master-branch caching possible is the second part of the PR that hooks up dry runs to master/stabilization branch pushes. These would make the dry-run workflow run every time you update your personal fork's master/stabilization branch. That dry run would likely finish very quickly if all caches are already in place. It would populate caches in master/stabilization branch in your personal fork, if not. 
> 
> The expected net result is that actual PRs that are branched off the personal fork master would be able to use the caches from that master workflow run. (If you want to make this experiment in current GHA, trigger the existing workflow on `master` branch in your fork, it would do roughly the same, but with all builds/tests).
> 
> A sample "dry-run" can be seen here: https://github.com/shipilev/jdk/actions/runs/16074619302. The most heavy-weight part is MSYS2 unpacking in Windows builds, and t...

It looks like you managed to get this down to a clear and nice improvement. Just remove the debug code and you're good to go :)

.github/workflows/main.yml line 172:

> 170:               fi
> 171: 
> 172:               # FOR TESTING, REMOVE BEFORE INTEGRATION

^^^

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26134#pullrequestreview-2987438070
PR Review Comment: https://git.openjdk.org/jdk/pull/26134#discussion_r2185492128

From sgehwolf at openjdk.org  Fri Jul  4 14:26:39 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Jul 2025 14:26:39 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow
In-Reply-To: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
Message-ID: <KbkZ7CJ_QoXhxZVCDfGH8oFU7jOPEraFUPf7CKGRRw8=.8a2ec9d5-b1e2-4782-a1b2-c91c78c5fdf6@github.com>

On Fri, 4 Jul 2025 13:21:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches.

Is a corollary of that that one ought to keep one's fork `master` branch in sync with the main repo's (`openjdk/jdk`) `master` branch? I usually only do this locally (on my work machine), but not on the github fork. Just making sure I understand this right.

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

PR Comment: https://git.openjdk.org/jdk/pull/26134#issuecomment-3036477280

From ihse at openjdk.org  Fri Jul  4 14:35:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Jul 2025 14:35:38 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow
In-Reply-To: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
Message-ID: <aD5CufKm825mQqupJEz7D3Tb38QmLByMmfKSFz1NqrY=.adf368d0-e066-4959-9136-3a5c60724a1f@github.com>

On Fri, 4 Jul 2025 13:21:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In our current GHA workflows, we only run workflows in branches in personal forks. GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches. For our branches, the usual parent is `master`. Since we do not run workflows on `master`, this means every time we create a new branch, GHA would start with logically empty caches for it. Only the next trigger on the same branch would use the caches, saved from the first workflow run.
> 
> This means we put additional load on shared infrastructure with pulling JDKs, building jtreg (and pulling its dependencies), bootstrapping sysroots, etc. All these steps also fail intermittently every so often. It also means everyone carries lots of caches around, segregated by branch and repo (look into your https://github.com/your-github-name/jdk/actions/caches, for example) only relying on cache cleanups when it starts to hit 10 GB. With hundreds of contributors, this easily wastes terabytes of cloud storage space.
> 
> We can make all this more efficient and reliable, if we manage to run a master-branch workflow that bootstraps all required dependencies and caches them. These dependencies can then be used by PR branches, as "master" branch is their effective parent. 
> 
> This PR introduces the notion of "dry run", which does everything _except_ the actual builds and tests. Therefore, it verifies whether all dependencies are done properly for JDK configure to pass. This is useful in itself for future GHA debugging of dependencies. Workflow can be dispatched with additional "dry run" parameter now.
> 
> What makes master-branch caching possible is the second part of the PR that hooks up dry runs to master/stabilization branch pushes. These would make the dry-run workflow run every time you update your personal fork's master/stabilization branch. That dry run would likely finish very quickly if all caches are already in place. It would populate caches in master/stabilization branch in your personal fork, if not. 
> 
> The expected net result is that actual PRs that are branched off the personal fork master would be able to use the caches from that master workflow run. (If you want to make this experiment in current GHA, trigger the existing workflow on `master` branch in your fork, it would do roughly the same, but with all builds/tests).
> 
> A sample "dry-run" can be seen here: https://github.com/shipilev/jdk/actions/runs/16074619302. The most heavy-weight part is MSYS2 unpacking in Windows builds, and t...

That seems like a reasonable interpretation, yes. At least if you want to utilize this optimization. Otoh, Github makes it really easy nowadays with a simple "sync with upstream" button (or whatever it's called).

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

PR Comment: https://git.openjdk.org/jdk/pull/26134#issuecomment-3036519454

From sgehwolf at openjdk.org  Fri Jul  4 14:39:38 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Jul 2025 14:39:38 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow
In-Reply-To: <aD5CufKm825mQqupJEz7D3Tb38QmLByMmfKSFz1NqrY=.adf368d0-e066-4959-9136-3a5c60724a1f@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
 <aD5CufKm825mQqupJEz7D3Tb38QmLByMmfKSFz1NqrY=.adf368d0-e066-4959-9136-3a5c60724a1f@github.com>
Message-ID: <u-SjQY0vclikPvO2f32OjTcgWDyHyHSLCSOmpk84P0M=.317dc6a5-d09a-4090-9792-6e0fcf7a82b2@github.com>

On Fri, 4 Jul 2025 14:32:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> That seems like a reasonable interpretation, yes. At least if you want to utilize this optimization. Otoh, Github makes it really easy nowadays with a simple "sync with upstream" button (or whatever it's called).

Thanks. It's not a problem for me. Nevertheless developers need to know that there is an opt-in of sorts for this caching to work for them.

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

PR Comment: https://git.openjdk.org/jdk/pull/26134#issuecomment-3036534250

From shade at openjdk.org  Fri Jul  4 15:30:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 4 Jul 2025 15:30:56 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow [v2]
In-Reply-To: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
Message-ID: <OG3z7OgCLfpmd9YLycYZ3D06er1LvAiAvnDxNRkeNTU=.74204cc7-3bfa-4c47-8f5f-3134a579996a@github.com>

> In our current GHA workflows, we only run workflows in branches in personal forks. GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches. For our branches, the usual parent is `master`. Since we do not run workflows on `master`, this means every time we create a new branch, GHA would start with logically empty caches for it. Only the next trigger on the same branch would use the caches, saved from the first workflow run.
> 
> This means we put additional load on shared infrastructure with pulling JDKs, building jtreg (and pulling its dependencies), bootstrapping sysroots, etc. All these steps also fail intermittently every so often. It also means everyone carries lots of caches around, segregated by branch and repo (look into your https://github.com/your-github-name/jdk/actions/caches, for example) only relying on cache cleanups when it starts to hit 10 GB. With hundreds of contributors, this easily wastes terabytes of cloud storage space.
> 
> We can make all this more efficient and reliable, if we manage to run a master-branch workflow that bootstraps all required dependencies and caches them. These dependencies can then be used by PR branches, as "master" branch is their effective parent. 
> 
> This PR introduces the notion of "dry run", which does everything _except_ the actual builds and tests. Therefore, it verifies whether all dependencies are done properly for JDK configure to pass. This is useful in itself for future GHA debugging of dependencies. Workflow can be dispatched with additional "dry run" parameter now.
> 
> What makes master-branch caching possible is the second part of the PR that hooks up dry runs to master/stabilization branch pushes. These would make the dry-run workflow run every time you update your personal fork's master/stabilization branch. That dry run would likely finish very quickly if all caches are already in place. It would populate caches in master/stabilization branch in your personal fork, if not. 
> 
> The expected net result is that actual PRs that are branched off the personal fork master would be able to use the caches from that master workflow run. (If you want to make this experiment in current GHA, trigger the existing workflow on `master` branch in your fork, it would do roughly the same, but with all builds/tests).
> 
> A sample "dry-run" can be seen here: https://github.com/shipilev/jdk/actions/runs/16074619302. The most heavy-weight part is MSYS2 unpacking in Windows builds, and t...

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

  Final touches

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26134/files
  - new: https://git.openjdk.org/jdk/pull/26134/files/bc087942..67b5be3d

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

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

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

From shade at openjdk.org  Fri Jul  4 15:30:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 4 Jul 2025 15:30:56 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow
In-Reply-To: <KbkZ7CJ_QoXhxZVCDfGH8oFU7jOPEraFUPf7CKGRRw8=.8a2ec9d5-b1e2-4782-a1b2-c91c78c5fdf6@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
 <KbkZ7CJ_QoXhxZVCDfGH8oFU7jOPEraFUPf7CKGRRw8=.8a2ec9d5-b1e2-4782-a1b2-c91c78c5fdf6@github.com>
Message-ID: <OkHvq4tQGbtpKQ0cSKg72slF1sR3_tSZjUnIJMiA-Mw=.a67cf4a6-ba35-44a1-835e-c043199360a8@github.com>

On Fri, 4 Jul 2025 14:24:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches.
> 
> Is a corollary of that that one ought to keep one's fork `master` branch in sync with the main repo's (`openjdk/jdk`) `master` branch? I usually only do this locally (on my work machine), but not on the github fork. Just making sure I understand this right.

Yes, I think that's right. If personal fork `master` is not updated on GH side, the caches would be missing/stale, and the "old" caching scheme takes over like before: the caches would be per branch. In other words, caching stuff in remote `master` is completely opportunistic.

Keeping in perfect sync is not needed, IMO, as GHA caches are keyed by `.github` contents hash. So caches would become stale only when GHA code is changed.

FWIW, I prefer to sync `master` in fork in my master every so often, and keep it in sync with upstream `master`. Usually through a magic button in UI, sometimes with fetch/push. The optimization like this would probably push towards the similar workflow. We should probably write it down somewhere, but I don't quite see where...

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

PR Comment: https://git.openjdk.org/jdk/pull/26134#issuecomment-3036683454

From sgehwolf at openjdk.org  Fri Jul  4 15:54:38 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 4 Jul 2025 15:54:38 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow
In-Reply-To: <OkHvq4tQGbtpKQ0cSKg72slF1sR3_tSZjUnIJMiA-Mw=.a67cf4a6-ba35-44a1-835e-c043199360a8@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
 <KbkZ7CJ_QoXhxZVCDfGH8oFU7jOPEraFUPf7CKGRRw8=.8a2ec9d5-b1e2-4782-a1b2-c91c78c5fdf6@github.com>
 <OkHvq4tQGbtpKQ0cSKg72slF1sR3_tSZjUnIJMiA-Mw=.a67cf4a6-ba35-44a1-835e-c043199360a8@github.com>
Message-ID: <N4z9XvsJakM1QeSzDgpuTV8BFo7nIAeLNj9WwS-Y5BA=.95f61d12-8419-4b6b-99f3-5ac9fc1fb911@github.com>

On Fri, 4 Jul 2025 15:23:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We should probably write it down somewhere, but I don't quite see where...

Maybe a heads-up to jdk-dev list would do and we have it in the list archives once this is in.

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

PR Comment: https://git.openjdk.org/jdk/pull/26134#issuecomment-3036754009

From ihse at openjdk.org  Fri Jul  4 20:35:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Jul 2025 20:35:38 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow [v2]
In-Reply-To: <OG3z7OgCLfpmd9YLycYZ3D06er1LvAiAvnDxNRkeNTU=.74204cc7-3bfa-4c47-8f5f-3134a579996a@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
 <OG3z7OgCLfpmd9YLycYZ3D06er1LvAiAvnDxNRkeNTU=.74204cc7-3bfa-4c47-8f5f-3134a579996a@github.com>
Message-ID: <IqTfW1NLl6mNpBryHm9wVlakcPvWdDCpfzzQvu-SkbA=.b3a4909b-1144-4108-9fae-505df8794e81@github.com>

On Fri, 4 Jul 2025 15:30:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In our current GHA workflows, we only run workflows in branches in personal forks. GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches. For our branches, the usual parent is `master`. Since we do not run workflows on `master`, this means every time we create a new branch, GHA would start with logically empty caches for it. Only the next trigger on the same branch would use the caches, saved from the first workflow run.
>> 
>> This means we put additional load on shared infrastructure with pulling JDKs, building jtreg (and pulling its dependencies), bootstrapping sysroots, etc. All these steps also fail intermittently every so often. It also means everyone carries lots of caches around, segregated by branch and repo (look into your https://github.com/your-github-name/jdk/actions/caches, for example) only relying on cache cleanups when it starts to hit 10 GB. With hundreds of contributors, this easily wastes terabytes of cloud storage space.
>> 
>> We can make all this more efficient and reliable, if we manage to run a master-branch workflow that bootstraps all required dependencies and caches them. These dependencies can then be used by PR branches, as "master" branch is their effective parent. 
>> 
>> This PR introduces the notion of "dry run", which does everything _except_ the actual builds and tests. Therefore, it verifies whether all dependencies are done properly for JDK configure to pass. This is useful in itself for future GHA debugging of dependencies. Workflow can be dispatched with additional "dry run" parameter now.
>> 
>> What makes master-branch caching possible is the second part of the PR that hooks up dry runs to master/stabilization branch pushes. These would make the dry-run workflow run every time you update your personal fork's master/stabilization branch. That dry run would likely finish very quickly if all caches are already in place. It would populate caches in master/stabilization branch in your personal fork, if not. 
>> 
>> The expected net result is that actual PRs that are branched off the personal fork master would be able to use the caches from that master workflow run. (If you want to make this experiment in current GHA, trigger the existing workflow on `master` branch in your fork, it would do roughly the same, but with all builds/tests).
>> 
>> A sample "dry-run" can be seen here: https://github.com/shipilev/jdk/actions/runs/16074619302. The most heavy-weight part is MSYS2 unpackin...
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Final touches

Yeah, a mail to jdk-dev would probably be good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26134#pullrequestreview-2988297474

From shade at openjdk.org  Mon Jul  7 08:26:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Jul 2025 08:26:48 GMT
Subject: Integrated: 8343546: GHA: Cache required dependencies in master-branch
 workflow
In-Reply-To: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
Message-ID: <5KtlMZREBQ4mYOOWi7KPRAlJg90TOf-M-1Y4o61DWRQ=.9bb075df-7058-433d-9b3a-d5fc4364c711@github.com>

On Fri, 4 Jul 2025 13:21:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In our current GHA workflows, we only run workflows in branches in personal forks. GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches. For our branches, the usual parent is `master`. Since we do not run workflows on `master`, this means every time we create a new branch, GHA would start with logically empty caches for it. Only the next trigger on the same branch would use the caches, saved from the first workflow run.
> 
> This means we put additional load on shared infrastructure with pulling JDKs, building jtreg (and pulling its dependencies), bootstrapping sysroots, etc. All these steps also fail intermittently every so often. It also means everyone carries lots of caches around, segregated by branch and repo (look into your https://github.com/your-github-name/jdk/actions/caches, for example) only relying on cache cleanups when it starts to hit 10 GB. With hundreds of contributors, this easily wastes terabytes of cloud storage space.
> 
> We can make all this more efficient and reliable, if we manage to run a master-branch workflow that bootstraps all required dependencies and caches them. These dependencies can then be used by PR branches, as "master" branch is their effective parent. 
> 
> This PR introduces the notion of "dry run", which does everything _except_ the actual builds and tests. Therefore, it verifies whether all dependencies are done properly for JDK configure to pass. This is useful in itself for future GHA debugging of dependencies. Workflow can be dispatched with additional "dry run" parameter now.
> 
> What makes master-branch caching possible is the second part of the PR that hooks up dry runs to master/stabilization branch pushes. These would make the dry-run workflow run every time you update your personal fork's master/stabilization branch. That dry run would likely finish very quickly if all caches are already in place. It would populate caches in master/stabilization branch in your personal fork, if not. 
> 
> The expected net result is that actual PRs that are branched off the personal fork master would be able to use the caches from that master workflow run. (If you want to make this experiment in current GHA, trigger the existing workflow on `master` branch in your fork, it would do roughly the same, but with all builds/tests).
> 
> A sample "dry-run" can be seen here: https://github.com/shipilev/jdk/actions/runs/16074619302. The most heavy-weight part is MSYS2 unpacking in Windows builds, and t...

This pull request has now been integrated.

Changeset: 1fa772e8
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1fa772e8143bb2d758ef183280d123d1ff8aada8
Stats:     94 lines in 7 files changed: 91 ins; 2 del; 1 mod

8343546: GHA: Cache required dependencies in master-branch workflow

Reviewed-by: ihse

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

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

From shade at openjdk.org  Mon Jul  7 08:26:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Jul 2025 08:26:47 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow [v2]
In-Reply-To: <OG3z7OgCLfpmd9YLycYZ3D06er1LvAiAvnDxNRkeNTU=.74204cc7-3bfa-4c47-8f5f-3134a579996a@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
 <OG3z7OgCLfpmd9YLycYZ3D06er1LvAiAvnDxNRkeNTU=.74204cc7-3bfa-4c47-8f5f-3134a579996a@github.com>
Message-ID: <fpH7ctpplzKBPN35dwTR7x42UO0dB_4lz3SjjCOJxk4=.b710da46-a014-49de-9eb2-e5bcb90aeec5@github.com>

On Fri, 4 Jul 2025 15:30:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In our current GHA workflows, we only run workflows in branches in personal forks. GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches. For our branches, the usual parent is `master`. Since we do not run workflows on `master`, this means every time we create a new branch, GHA would start with logically empty caches for it. Only the next trigger on the same branch would use the caches, saved from the first workflow run.
>> 
>> This means we put additional load on shared infrastructure with pulling JDKs, building jtreg (and pulling its dependencies), bootstrapping sysroots, etc. All these steps also fail intermittently every so often. It also means everyone carries lots of caches around, segregated by branch and repo (look into your https://github.com/your-github-name/jdk/actions/caches, for example) only relying on cache cleanups when it starts to hit 10 GB. With hundreds of contributors, this easily wastes terabytes of cloud storage space.
>> 
>> We can make all this more efficient and reliable, if we manage to run a master-branch workflow that bootstraps all required dependencies and caches them. These dependencies can then be used by PR branches, as "master" branch is their effective parent. 
>> 
>> This PR introduces the notion of "dry run", which does everything _except_ the actual builds and tests. Therefore, it verifies whether all dependencies are done properly for JDK configure to pass. This is useful in itself for future GHA debugging of dependencies. Workflow can be dispatched with additional "dry run" parameter now.
>> 
>> What makes master-branch caching possible is the second part of the PR that hooks up dry runs to master/stabilization branch pushes. These would make the dry-run workflow run every time you update your personal fork's master/stabilization branch. That dry run would likely finish very quickly if all caches are already in place. It would populate caches in master/stabilization branch in your personal fork, if not. 
>> 
>> The expected net result is that actual PRs that are branched off the personal fork master would be able to use the caches from that master workflow run. (If you want to make this experiment in current GHA, trigger the existing workflow on `master` branch in your fork, it would do roughly the same, but with all builds/tests).
>> 
>> A sample "dry-run" can be seen here: https://github.com/shipilev/jdk/actions/runs/16074619302. The most heavy-weight part is MSYS2 unpackin...
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Final touches

OK, I'll write something up to jdk-dev after we are sure it works well. I'll integrate and watch what happens.

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

PR Comment: https://git.openjdk.org/jdk/pull/26134#issuecomment-3043952452

From shade at openjdk.org  Mon Jul  7 09:16:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Jul 2025 09:16:51 GMT
Subject: RFR: 8343546: GHA: Cache required dependencies in master-branch
 workflow [v2]
In-Reply-To: <OG3z7OgCLfpmd9YLycYZ3D06er1LvAiAvnDxNRkeNTU=.74204cc7-3bfa-4c47-8f5f-3134a579996a@github.com>
References: <QSffQ_1OmAouwwG-s9ASR1HXZd3HMbfNfYOYC_eMRBA=.3b781511-aca4-48ff-aa7d-ce177702d050@github.com>
 <OG3z7OgCLfpmd9YLycYZ3D06er1LvAiAvnDxNRkeNTU=.74204cc7-3bfa-4c47-8f5f-3134a579996a@github.com>
Message-ID: <srpfQHPLtjMqiQmuNwQZTzB1-uGXPZRuuQTajllD-iU=.f5059bfa-7e70-453d-8cc9-78902b501237@github.com>

On Fri, 4 Jul 2025 15:30:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In our current GHA workflows, we only run workflows in branches in personal forks. GHA isolation rules say that workflow caches from the parent branches can be used by descendant branches. For our branches, the usual parent is `master`. Since we do not run workflows on `master`, this means every time we create a new branch, GHA would start with logically empty caches for it. Only the next trigger on the same branch would use the caches, saved from the first workflow run.
>> 
>> This means we put additional load on shared infrastructure with pulling JDKs, building jtreg (and pulling its dependencies), bootstrapping sysroots, etc. All these steps also fail intermittently every so often. It also means everyone carries lots of caches around, segregated by branch and repo (look into your https://github.com/your-github-name/jdk/actions/caches, for example) only relying on cache cleanups when it starts to hit 10 GB. With hundreds of contributors, this easily wastes terabytes of cloud storage space.
>> 
>> We can make all this more efficient and reliable, if we manage to run a master-branch workflow that bootstraps all required dependencies and caches them. These dependencies can then be used by PR branches, as "master" branch is their effective parent. 
>> 
>> This PR introduces the notion of "dry run", which does everything _except_ the actual builds and tests. Therefore, it verifies whether all dependencies are done properly for JDK configure to pass. This is useful in itself for future GHA debugging of dependencies. Workflow can be dispatched with additional "dry run" parameter now.
>> 
>> What makes master-branch caching possible is the second part of the PR that hooks up dry runs to master/stabilization branch pushes. These would make the dry-run workflow run every time you update your personal fork's master/stabilization branch. That dry run would likely finish very quickly if all caches are already in place. It would populate caches in master/stabilization branch in your personal fork, if not. 
>> 
>> The expected net result is that actual PRs that are branched off the personal fork master would be able to use the caches from that master workflow run. (If you want to make this experiment in current GHA, trigger the existing workflow on `master` branch in your fork, it would do roughly the same, but with all builds/tests).
>> 
>> A sample "dry-run" can be seen here: https://github.com/shipilev/jdk/actions/runs/16074619302. The most heavy-weight part is MSYS2 unpackin...
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Final touches

Yeah, see how it works.

0. I removed all caches in https://github.com/shipilev/jdk/actions/caches
1. I pulled `openjdk:master` to `shipilev:master`
2. The `master` dry-run was immediately auto-triggered and completed in ~20 minutes, mostly stuck on sysroot creations.  I triggered manual re-runs of that workflow on `master` branch. The re-runs, now with full caches took ~10 minutes, mostly driven by MSYS2 install times. https://github.com/shipilev/jdk/actions/runs/16111802273
3. I merged `master` into my feature branch [JDK-8361397-compilelog-list](https://github.com/shipilev/jdk/tree/JDK-8361397-compilelog-list), pushed, and it triggered the GHA run, which used the caches: https://github.com/shipilev/jdk/actions/runs/16112659046

So far I think it works as expected.

I also found the opportunity for MSYS2: [JDK-8361478](https://bugs.openjdk.org/browse/JDK-8361478).

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

PR Comment: https://git.openjdk.org/jdk/pull/26134#issuecomment-3044116386

From shade at openjdk.org  Mon Jul  7 13:00:20 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Jul 2025 13:00:20 GMT
Subject: RFR: 8361478: GHA: Use MSYS2 from GHA runners
Message-ID: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>

Installing MSYS2 takes considerable time in our Windows workflows. Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step say it is enough to say `release: false` to use those:
 https://github.com/msys2/setup-msys2?tab=readme-ov-file#release

Also bumping the action version to gain access to the actual installed path.

Additional testing:
 - [x] GHA

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

Commit messages:
 - Fix

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

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

From duke at openjdk.org  Mon Jul  7 15:40:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:40:50 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
Message-ID: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.

Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'openjdk:master' into jdk-8361188
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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

From duke at openjdk.org  Mon Jul  7 17:53:52 2025
From: duke at openjdk.org (Daniel Hu)
Date: Mon, 7 Jul 2025 17:53:52 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not load
 the entire file at once
Message-ID: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>

These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.

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

Commit messages:
 - remove 8341024
 - remove trailing whitespace
 - fix

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

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

From cslucas at openjdk.org  Mon Jul  7 18:27:39 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 7 Jul 2025 18:27:39 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once
In-Reply-To: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
Message-ID: <pAt9JZWJTmtffP0_fI5UvRFbHXvDjv0BEV5vkH8TkkE=.a7a9967d-97d2-4175-b499-48ca7c137bc6@github.com>

On Fri, 27 Jun 2025 23:29:15 GMT, Daniel Hu <duke at openjdk.org> wrote:

> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.

test/jdk/build/AbsPathsInImage.java line 186:

> 184:         byte[] buffer = new byte[8192];
> 185:         List<String> matches = new ArrayList<>();
> 186:         try(InputStream inputStream = Files.newInputStream(file)) {

NIT: space after `try`?

test/jdk/build/AbsPathsInImage.java line 204:

> 202:         ZipEntry zipEntry;
> 203:         int bytesRead;
> 204:         byte[] buffer = new byte[8192];

NIT: would be cleaner if the `8192` were a constant in the test class itself.

test/jdk/build/AbsPathsInImage.java line 208:

> 206:             while ((zipEntry = zipInputStream.getNextEntry()) != null) {
> 207:                 List<String> matches = new ArrayList<>();
> 208:                 while((bytesRead = zipInputStream.read(buffer)) != -1) {

NIT: space after `while`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26030#discussion_r2190773742
PR Review Comment: https://git.openjdk.org/jdk/pull/26030#discussion_r2190773440
PR Review Comment: https://git.openjdk.org/jdk/pull/26030#discussion_r2190771622

From cslucas at openjdk.org  Mon Jul  7 18:27:39 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 7 Jul 2025 18:27:39 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once
In-Reply-To: <pAt9JZWJTmtffP0_fI5UvRFbHXvDjv0BEV5vkH8TkkE=.a7a9967d-97d2-4175-b499-48ca7c137bc6@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
 <pAt9JZWJTmtffP0_fI5UvRFbHXvDjv0BEV5vkH8TkkE=.a7a9967d-97d2-4175-b499-48ca7c137bc6@github.com>
Message-ID: <8TUiuKoP_zouo0AWX46gvpmAnlyckPy8Q5RtNq8AcIM=.9ed1a1a8-bb55-409f-ac1d-4323187f4de7@github.com>

On Mon, 7 Jul 2025 18:22:22 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.
>
> test/jdk/build/AbsPathsInImage.java line 186:
> 
>> 184:         byte[] buffer = new byte[8192];
>> 185:         List<String> matches = new ArrayList<>();
>> 186:         try(InputStream inputStream = Files.newInputStream(file)) {
> 
> NIT: space after `try`?

same for the `while` below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26030#discussion_r2190777987

From jwaters at openjdk.org  Tue Jul  8 11:38:39 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 8 Jul 2025 11:38:39 GMT
Subject: RFR: 8361478: GHA: Use MSYS2 from GHA runners
In-Reply-To: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
References: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
Message-ID: <xQYNwWmp9CFix1yC_TpYDdX707Y1TyGgJhu8aEnC2YE=.88c7731c-8e13-4632-bb6e-615b137f0e50@github.com>

On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Installing MSYS2 takes considerable time in our Windows workflows. Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step say it is enough to say `release: false` to use those:
>  https://github.com/msys2/setup-msys2?tab=readme-ov-file#release
> 
> Also bumping the action version to gain access to the actual installed path.
> 
> Additional testing:
>  - [x] GHA

I recall there were some issues with using MSYS2 that comes with Actions. That was a long time ago though, are they no longer a problem with current Actions and MSYS2 versions?

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

PR Comment: https://git.openjdk.org/jdk/pull/26156#issuecomment-3048539668

From shade at openjdk.org  Tue Jul  8 12:53:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 12:53:38 GMT
Subject: RFR: 8361478: GHA: Use MSYS2 from GHA runners
In-Reply-To: <xQYNwWmp9CFix1yC_TpYDdX707Y1TyGgJhu8aEnC2YE=.88c7731c-8e13-4632-bb6e-615b137f0e50@github.com>
References: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
 <xQYNwWmp9CFix1yC_TpYDdX707Y1TyGgJhu8aEnC2YE=.88c7731c-8e13-4632-bb6e-615b137f0e50@github.com>
Message-ID: <IWBkH41EaoOeQwjC0GdQ9oBXpuZl_q6xRJQ3fCJXg-s=.16581438-59bf-4c33-be07-067278d5fc94@github.com>

On Tue, 8 Jul 2025 11:35:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I recall there were some issues with using MSYS2 that comes with Actions. That was a long time ago though, are they no longer a problem with current Actions and MSYS2 versions?

We used to have a problem building jtreg, so we pinned and later unpinned the version: [JDK-8310259](https://bugs.openjdk.org/browse/JDK-8310259). But today, we do not build jtreg on Windows at all. And we have not seen any issues with MSYS2 since. So I think it is okay to bump the version now. We can retract it back if we find problems, it would only require rewiring the `PATH` a bit awkwardly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26156#issuecomment-3048827047

From duke at openjdk.org  Tue Jul  8 20:55:17 2025
From: duke at openjdk.org (Daniel Hu)
Date: Tue, 8 Jul 2025 20:55:17 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once [v2]
In-Reply-To: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
Message-ID: <Yr1ymhPFEzBkGSWpVGquzUbjvAxm4ZRaWmcHCjKZ85U=.c7d87809-0b82-4380-b5e8-236f9d522f08@github.com>

> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.

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

  style improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26030/files
  - new: https://git.openjdk.org/jdk/pull/26030/files/5d880ecb..eb63b162

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

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

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

From mikael at openjdk.org  Tue Jul  8 21:06:38 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 8 Jul 2025 21:06:38 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once [v2]
In-Reply-To: <Yr1ymhPFEzBkGSWpVGquzUbjvAxm4ZRaWmcHCjKZ85U=.c7d87809-0b82-4380-b5e8-236f9d522f08@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
 <Yr1ymhPFEzBkGSWpVGquzUbjvAxm4ZRaWmcHCjKZ85U=.c7d87809-0b82-4380-b5e8-236f9d522f08@github.com>
Message-ID: <4daiHAVSVWvUTRvKbnFT_iyq2_hEqKFGL7LgIaA8L1Q=.36df989a-3c32-4bb6-947c-0934ee4e2bd1@github.com>

On Tue, 8 Jul 2025 20:55:17 GMT, Daniel Hu <duke at openjdk.org> wrote:

>> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.
>
> Daniel Hu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style improvements

Sorry for the potentially stupid question but: what happens if the pattern spans a chunk?

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

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

From jwaters at openjdk.org  Wed Jul  9 09:31:39 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 9 Jul 2025 09:31:39 GMT
Subject: RFR: 8361478: GHA: Use MSYS2 from GHA runners
In-Reply-To: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
References: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
Message-ID: <HQS8n6MOvW7vM55GrLGak2E2YuNs56xXHOJoKj_ztv0=.6af50c3b-5b5d-4474-9592-1eb2fccf93c3@github.com>

On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Installing MSYS2 takes considerable time in our Windows workflows. Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step say it is enough to say `release: false` to use those:
>  https://github.com/msys2/setup-msys2?tab=readme-ov-file#release
> 
> Also bumping the action version to gain access to the actual installed path.
> 
> Additional testing:
>  - [x] GHA

I think the problem was something else about Actions MSYS2 not being usable, but alas I can't remember enough to actually make a valid point. So this gets a +1 from me since it can easily be backed out if it does cause issues. I'm not a Reviewer though, so you'll have to wait for Magnus to take a look at this

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26156#pullrequestreview-3000765326

From shade at openjdk.org  Wed Jul  9 14:56:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 14:56:38 GMT
Subject: RFR: 8361478: GHA: Use MSYS2 from GHA runners
In-Reply-To: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
References: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
Message-ID: <6yK-HhPThDZ9oxDdehIG36P-qWcx9n6V92IzeyQGRRo=.5ff863ba-0dd6-406e-9bc4-a33e64e1175e@github.com>

On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Installing MSYS2 takes considerable time in our Windows workflows. Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step say it is enough to say `release: false` to use those:
>  https://github.com/msys2/setup-msys2?tab=readme-ov-file#release
> 
> Also bumping the action version to gain access to the actual installed path.
> 
> Additional testing:
>  - [x] GHA

Hey @magicus ;)

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

PR Comment: https://git.openjdk.org/jdk/pull/26156#issuecomment-3052968554

From duke at openjdk.org  Wed Jul  9 21:17:17 2025
From: duke at openjdk.org (Daniel Hu)
Date: Wed, 9 Jul 2025 21:17:17 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once [v3]
In-Reply-To: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
Message-ID: <DZL30c1HMuqV7f2I-4k5Cj8Ib6CtfKuYdaCED-KQq-A=.e19887d6-fa2c-4113-92a6-47a6925b7364@github.com>

> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.

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

  redid byte matching which should fix cross chunk strings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26030/files
  - new: https://git.openjdk.org/jdk/pull/26030/files/eb63b162..ef391ba9

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

  Stats: 56 lines in 1 file changed: 5 ins; 25 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26030/head:pull/26030

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

From duke at openjdk.org  Wed Jul  9 22:28:56 2025
From: duke at openjdk.org (Daniel Hu)
Date: Wed, 9 Jul 2025 22:28:56 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once [v4]
In-Reply-To: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
Message-ID: <CcbJWdSwy7zaEE1E9KSPvO8HlF66465Ox8xu_6QhYAU=.c46723f7-fce6-49cf-9ae6-1053f7c942af@github.com>

> These changes should prevent entire binary files from being loaded into memory for build/AbsPathsInImage.java test. I chose a default buffer size of 8KB since BufferedInputStream uses that, but open to alternative solutions. GHA passes and test passes on linux x64.

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

 - Merge branch 'openjdk:master' into 8341735
 - redid byte matching which should fix cross chunk strings
 - style improvements
 - remove 8341024
 - remove trailing whitespace
 - fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26030/files
  - new: https://git.openjdk.org/jdk/pull/26030/files/ef391ba9..c3d7a77b

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

  Stats: 15631 lines in 580 files changed: 9131 ins; 2505 del; 3995 mod
  Patch: https://git.openjdk.org/jdk/pull/26030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26030/head:pull/26030

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

From duke at openjdk.org  Wed Jul  9 22:38:38 2025
From: duke at openjdk.org (Daniel Hu)
Date: Wed, 9 Jul 2025 22:38:38 GMT
Subject: RFR: 8341735: Rewrite the build/AbsPathsInImage.java test to not
 load the entire file at once [v2]
In-Reply-To: <4daiHAVSVWvUTRvKbnFT_iyq2_hEqKFGL7LgIaA8L1Q=.36df989a-3c32-4bb6-947c-0934ee4e2bd1@github.com>
References: <SesjO5SWoOG8EKm2qWK0HGgXC8A77DRMShJC5xLsHig=.f2f998ae-2ff0-4031-9781-b247333d19de@github.com>
 <Yr1ymhPFEzBkGSWpVGquzUbjvAxm4ZRaWmcHCjKZ85U=.c7d87809-0b82-4380-b5e8-236f9d522f08@github.com>
 <4daiHAVSVWvUTRvKbnFT_iyq2_hEqKFGL7LgIaA8L1Q=.36df989a-3c32-4bb6-947c-0934ee4e2bd1@github.com>
Message-ID: <o1cSOnUDRodbBa3qvsKLlkBF3WUSio8AjqEb2-hQZUs=.a5a16c92-1efb-4a6f-9c5d-f0d6ffb93f1c@github.com>

On Tue, 8 Jul 2025 21:03:40 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Sorry for the potentially stupid question but: what happens if the pattern spans a chunk?

Thanks for catching that! I should've been more careful. Rewrote the byte matching completely to accommodate, but now test takes twice as long... also new scan function operates under assumption that no non-printable ascii bytes within searchPatterns. I profiled the new test but nothing obvious at why the new function takes longer... (I suppose reading single byte at a time is bad, but I assumed a buffered stream would negate that). I'll do more debugging; I tried converting the patterns to strings thinking using library string matching algorithm might be an improvement, but that didn't yield improvements on my local unfortunately.

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

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

From matthias.baesken at sap.com  Thu Jul 10 15:23:48 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 10 Jul 2025 15:23:48 +0000
Subject: hotspot jtreg tests take  WARNING_CFLAGS_JDK_CONLY  flags
Message-ID: <AM9PR02MB6770334B693A05E91D313E619348A@AM9PR02MB6770.eurprd02.prod.outlook.com>

When  trying the GCC static analyzer (-fanalyzer flag)


diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
index e80d9a98957..9d1ae60047b 100644
--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -610,7 +610,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
   # CFLAGS WARNINGS STUFF
   # Set JVM_CFLAGS warning handling
   if test "x$TOOLCHAIN_TYPE" = xgcc; then
-    WARNING_CFLAGS_JDK_CONLY="$WARNINGS_ENABLE_ALL_CFLAGS"
+    # enable -fanalyzer (but better only for gcc12 + , and also only for C)
+    # too many strange / shaky fd leak warnings
+    WARNING_CFLAGS_JDK_CONLY="-fanalyzer -Wno-analyzer-fd-leak $WARNINGS_ENABLE_ALL_CFLAGS"
     WARNING_CFLAGS_JDK_CXXONLY="$WARNINGS_ENABLE_ALL_CXXFLAGS"
     WARNING_CFLAGS_JVM="$WARNINGS_ENABLE_ALL_CXXFLAGS"

I noticed that the   WARNING_CFLAGS_JDK_CONLY  go into the  hotspot   jtreg tests, e.g.  :


/jdk/test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h:46:6: error: dereference of NULL '0' [CWE-476] [-Werror=analyzer-null-dereference]
   46 |   *x = 34; // Crash
      |   ~~~^~~~
  'dereference_null': event 1
    |
    |   46 |   *x = 34; // Crash
    |      |   ~~~^~~~
    |      |      |
    |      |      (1) dereference of NULL '0'


This might be intended but   I was surprised that the HS  C tests take  WARNING_CFLAGS_JDK_CONLY    !?   Is this intended or not ?


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

From cstein at openjdk.org  Fri Jul 11 09:10:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 11 Jul 2025 09:10:19 GMT
Subject: RFR: JDK-8289798: Update to use jtreg 8
Message-ID: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>

Please review the change to update to using jtreg 8.

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

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

Commit messages:
 - 8361950: Set required version to 8+2
 - 8361950: Update to use jtreg 8

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

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

From matthias.baesken at sap.com  Fri Jul 11 12:57:43 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 11 Jul 2025 12:57:43 +0000
Subject: malloc/calloc return value NULL check
Message-ID: <AM9PR02MB6770B34C68E9C8DDC337A80F934BA@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hi, when playing around with the  GCC static analyzer  ( https://developers.redhat.com/articles/2022/04/12/state-static-analysis-gcc-12-compiler )   I noticed
a lot of complaints about  missing  NULL checks of  malloc/calloc  return values in the code base.

While we check these return values for NULL at a lot of places in the codebase,  it is not done always.
Should we do it always  (except 3rd party code probably where we do not want to have large diffs to upstream) ?

Or is it considered not important enough  to do it always?

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

From thomas.stuefe at gmail.com  Fri Jul 11 16:19:22 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 11 Jul 2025 18:19:22 +0200
Subject: malloc/calloc return value NULL check
In-Reply-To: <AM9PR02MB6770B34C68E9C8DDC337A80F934BA@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770B34C68E9C8DDC337A80F934BA@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUzS1gBjH6=EFvjGJU6zLpWZoUzLda=qzN8t=NSuJMt9qw@mail.gmail.com>

Absolutely, yes.

The larger the allocated size, the more important. Linux kernel, by
default, only protects a small area against NULL accesses; depending on
distro, 4KB or 64 (?) KB. And the JVM, at various places, allocates in
low-area ranges. So accessing NULL+<large offset> can actually land you at
a valid unrelated address instead of faulting.

/Thomas

On Fri, Jul 11, 2025 at 2:57?PM Baesken, Matthias <matthias.baesken at sap.com>
wrote:

> Hi, when playing around with the  GCC static analyzer  (
> https://developers.redhat.com/articles/2022/04/12/state-static-analysis-gcc-12-compiler
> )   I noticed
>
> a lot of complaints about  missing  NULL checks of  malloc/calloc  return
> values in the code base.
>
>
>
> While we check these return values for NULL at a lot of places in the
> codebase,  it is not done always.
>
> Should we do it always  (except 3rd party code probably where we do not
> want to have large diffs to upstream) ?
>
>
>
> Or is it considered not important enough  to do it always?
>
>
>
> Best regards, Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250711/39af3490/attachment-0001.htm>

From iris at openjdk.org  Fri Jul 11 17:42:38 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 11 Jul 2025 17:42:38 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <hNvkWs8N0batlQY3XmA-hnwS_Z6Tc5DFIAusJSOoaDI=.0b5f04b6-643a-4c59-babb-f313b362f4ca@github.com>

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

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

Marked as reviewed by iris (Reviewer).

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

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

From joehw at openjdk.org  Fri Jul 11 17:52:39 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 11 Jul 2025 17:52:39 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <0DTztUpAJe-j6cGqC33j6xyeTb1W_dFdaP65Z7f6NFk=.7bb3d63e-2a5a-4a95-93d2-9249285bcf70@github.com>

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

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

test/jaxp/TEST.ROOT looks good.

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

Marked as reviewed by joehw (Reviewer).

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

From duke at openjdk.org  Fri Jul 11 23:03:50 2025
From: duke at openjdk.org (duke)
Date: Fri, 11 Jul 2025 23:03:50 GMT
Subject: Withdrawn: 8352044: Add --with-import-jvms to configure
In-Reply-To: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
References: <6aXXBRPoI9bk60r4oSt57ZT49tV7aEzfD5FrDmfjMIs=.d2c26851-3826-4e6d-a813-8b711fccc00a@github.com>
Message-ID: <SYBbqtdJjQFvEsh7QM2IrbA6KBPAenCetQej7EUFKMA=.33b20e76-05cd-4b62-9551-cc93de75a9c2@github.com>

On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should allow pre-built JVMs to be included in a build, so they are just copied into place, and the jvm.cfg file properly updated.

This pull request has been closed without being integrated.

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

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

From david.holmes at oracle.com  Mon Jul 14 03:28:09 2025
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Jul 2025 13:28:09 +1000
Subject: malloc/calloc return value NULL check
In-Reply-To: <AM9PR02MB6770B34C68E9C8DDC337A80F934BA@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB6770B34C68E9C8DDC337A80F934BA@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <3eb406f9-d839-4d90-a34a-6b068ccf7cc3@oracle.com>

On 11/07/2025 10:57 pm, Baesken, Matthias wrote:
> Hi, when playing around with the? GCC static analyzer ?( https:// 
> developers.redhat.com/articles/2022/04/12/state-static-analysis-gcc-12- 
> compiler <https://developers.redhat.com/articles/2022/04/12/state- 
> static-analysis-gcc-12-compiler> )?? I noticed
> 
> a lot of complaints about? missing? NULL checks of? malloc/calloc 
>  ?return values in the code base.

In hotspot codebase ??

> While we check these return values for NULL at a lot of places in the 
> codebase,? it is not done always.
> 
> Should we do it always? (except 3^rd party code probably where we do not 
> want to have large diffs to upstream) ?
> 
> Or is it considered not important enough ?to do it always?

Yes we should be checking for null returns.

Why did you raise this on build-dev??

David
-----

> Best regards, Matthias
> 


From sherman at openjdk.org  Mon Jul 14 04:58:45 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 04:58:45 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII range
 does not match ASCII char
Message-ID: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>

Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.

This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?

To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".

**RL1.5 states**: 

To meet this requirement, an implementation that supports case-sensitive matching should

    1. Provide at least the simple, default Unicode case-insensitive matching, and
    2. Specify which character properties or constructs are closed under the matching.

**In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:

    1. back-refs
    2. string slices (sequences)
    3. single character,
    4. character families (Unicode Properties ...), and
    5. character class ranges

**Note**: Single characters and families may appear independently or within a character class.

For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.

This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.

For example:

Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true

The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).

**Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.

Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
vs
Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true

vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)

perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**

The root issue is that the range construct is not implemented to be closed under simple case folding. Applying toUpperCase() and toLowerCase() to a range like [\u0170-\u0180] does not produce a meaningful or valid range for case-folding comparisons. For example [\u0170-\u0180]  => [\u0053-\u243] with uppercase conversion. 

**What This PR Does**
This PR adds support for ensuring that character class ranges are closed under simple case folding when the (?ui) (Unicode case-insensitive) flag is used, bringing Pattern into better conformance with UTS #18 Level 1 (RL1.5).

**Notes**

**(1) The PR also tries to fix a special corner case for U+00df** 
see:  https://codepoints.net/U+00DF vs  https://codepoints.net/U+1E9E?lang=en for more context.

Pattern.compile("(?ui)\u00df").matcher("\u1e9e").matches() => false
Pattern.compile("(?ui)\u1e9f").matcher("\u00df").matches()  => false

vs

perl -C -e 'print "\x{1e9e}" =~ /\x{df}/ ? "true\n" : "false\n"'  => false
perl -C -e 'print "\x{df}" =~ /\x{1e9e}/ ? "true\n" : "false\n"'  => false
perl -C -e 'print "\x{1e9e}" =~ /\x{df}/i ? "true\n" : "false\n"'  => true
perl -C -e 'print "\x{df}" =~ /\x{1e9e}/i ? "true\n" : "false\n"'  => true

The Java Character class still CORRECTLY returns u+00df for its upper case, as suggested by the Unicode. So our toUpperCase() != toLowerCase() in single() implementation fails to pick SingleU for case-insensitive matching as expected.  

Integer.toHexString(Character.toUpperCase('\u00df')) => 0xdf

**(2) Known limitations: 3 'S'-like characters still fail**

There are 3 characters whose case folding mappings (per CaseFolding.txt) are not captured by our current logic, which relies only on Java's toUpperCase()/toLowerCase() conversions. These characters cannot be matched across constructs like back-ref, slice, single, or range using the current API. We will leave them unchanged for now, pending a possible migration to a pure case folding based matching implementation.

1FD3; S; 0390; # GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA
1FE3; S; 03B0; # GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA
FB05; S; FB06; # LATIN SMALL LIGATURE LONG S T

**Refs**:
https://bugs.openjdk.org/browse/JDK-6486934
https://bugs.openjdk.org/browse/CCC-6486934
https://cr.openjdk.org/~sherman/6486934_6233084_6504326_6436458/

We are fixing an almost 20-year old bug :-)

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

Commit messages:
 - 8360459: UNICODE_CASE and character class with non-ASCII range does not match ASCII char

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

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

From liach at openjdk.org  Mon Jul 14 05:12:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 05:12:40 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>

On Mon, 14 Jul 2025 04:53:13 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?
> 
> To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]")....

make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 45:

> 43:         var caseFoldingTxt = Paths.get(args[1]);
> 44:         var genSrcFile = Paths.get(args[2]);
> 45:         var supportedTypes = "^.*; [CTS]; .*$";

Do we still need T here given you already have a hardcoded special case?

make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 60:

> 58:                 .map(cols -> String.format("        entry(0x%s, 0x%s),", cols[0], cols[2]))
> 59:                 .collect(Collectors.joining("\n"))
> 60:                 .replaceFirst(",$", "");  // remove the last ','

Suggestion:

                .map(cols -> String.format("        entry(0x%s, 0x%s)", cols[0], cols[2]))
                .collect(Collectors.joining(",\n", "", "\n"));  // remove the last ','

make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 74:

> 72:                 StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING);
> 73:         } catch (IOException e) {
> 74:             e.printStackTrace();

I recommend removing this catch and add `throws Throwable` in the signature of `main`

src/java.base/share/classes/jdk/internal/util/regex/CaseFolding.java.template line 36:

> 34: public final class CaseFolding {
> 35: 
> 36:     private static Map<Integer, Integer> expanded_casefolding = Map.ofEntries(

Suggestion:

    private static final Map<Integer, Integer> expanded_casefolding = Map.ofEntries(

src/java.base/share/classes/jdk/internal/util/regex/CaseFolding.java.template line 99:

> 97:      */
> 98:     public static int[] getClassRangeClosingCharacters(int start, int end) {
> 99:         int[] expanded = new int[expanded_casefolding.size()];

Can be `Math.min(expanded_casefolding.size(), end - start)` in case the table grows large, and update the `off < expanded.length` check below too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203858280
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203854636
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203852720
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203850027
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2203851719

From sherman at openjdk.org  Mon Jul 14 07:30:45 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 07:30:45 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char
In-Reply-To: <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
Message-ID: <6AFn-UzXqb_oY_XGpadyiepteLDrlHJsSqZfXrybPug=.c8454bbe-15df-463a-8e6c-53022ece337b@github.com>

On Mon, 14 Jul 2025 05:01:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?
>> 
>> To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u...
>
> src/java.base/share/classes/jdk/internal/util/regex/CaseFolding.java.template line 99:
> 
>> 97:      */
>> 98:     public static int[] getClassRangeClosingCharacters(int start, int end) {
>> 99:         int[] expanded = new int[expanded_casefolding.size()];
> 
> Can be `Math.min(expanded_casefolding.size(), end - start)` in case the table grows large, and update the `off < expanded.length` check below too.

The table itself probably isn't going to grow significantly anytime soon, and we?ll likely have enough time to adjust if CaseFolding.txt does get substantially bigger.

That said, I probably should consider reversing the lookup logic: instead of iterating through [start, end], we could iterate over the expansion table and check whether any of its code points fall within the input range, at least when the range size is larger than the size of the table, kinda O(n) vs O(1)-ish.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2204044141

From sherman at openjdk.org  Mon Jul 14 07:54:31 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 07:54:31 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v2]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <9h1T1edYRoTT3v5CPkY9DN9Lq0bSnDoU8VtK2xn4sIA=.9b57eb79-b59e-4b59-a2ed-94b68735c04f@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?
> 
> To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]")....

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

  update to address the review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/640d7a61..735bd722

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

  Stats: 40 lines in 2 files changed: 7 ins; 12 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/26285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26285/head:pull/26285

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

From sherman at openjdk.org  Mon Jul 14 07:58:39 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 07:58:39 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v2]
In-Reply-To: <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
Message-ID: <FjtJX3d3N6G-cU1UubzPHZIrDJIX4TGmnwRVIW387nk=.223ca743-aff0-46f2-a051-9068b8f55f8b@github.com>

On Mon, 14 Jul 2025 05:08:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to address the review comments
>
> make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 45:
> 
>> 43:         var caseFoldingTxt = Paths.get(args[1]);
>> 44:         var genSrcFile = Paths.get(args[2]);
>> 45:         var supportedTypes = "^.*; [CTS]; .*$";
> 
> Do we still need T here given you already have a hardcoded special case?

Yes, there is another T entry for the 'I's that is picked by the logic

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2204103748

From naoto at openjdk.org  Mon Jul 14 18:14:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 18:14:48 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v2]
In-Reply-To: <9h1T1edYRoTT3v5CPkY9DN9Lq0bSnDoU8VtK2xn4sIA=.9b57eb79-b59e-4b59-a2ed-94b68735c04f@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <9h1T1edYRoTT3v5CPkY9DN9Lq0bSnDoU8VtK2xn4sIA=.9b57eb79-b59e-4b59-a2ed-94b68735c04f@github.com>
Message-ID: <AZoyQaqBTkKTCt1R05DWBsFQXyYJJ87VoEn4djB8JfM=.2afebbe4-23fc-42e7-b4d1-ab1ab62fcb8d@github.com>

On Mon, 14 Jul 2025 07:54:31 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?closed.?
>> 
>> To conform with Level 1 of UTS #18, specifically RL1.5: Simple Loose Matches, simple case folding must be applied to literals and (optionally) to character classes. When applied to character classes, each character class is expected to **be closed under simple case folding**.  See the standard for the detailed explanation and example of "closed".
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to address the review comments

Looks good. Thanks for adding case folding support which is long overdue ?
Since this is adding a new support for casefolding for character class ranges, I think CSR and a release note should be considered.

make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java line 73:

> 71:             StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING);
> 72:     }
> 73: }

Needs a NL at the end

test/jdk/java/util/regex/CaseFoldingTest.java line 30:

> 28:  * @library /lib/testlibrary/java/lang
> 29:  * @author Xueming Shen
> 30:  * @run testng CaseFoldingTest

Since this is a new test, I think we prefer junit over testng

test/jdk/java/util/regex/CaseFoldingTest.java line 61:

> 59: 
> 60:         var results = Files.readAllLines(UCDFiles.CASEFOLDING)
> 61:             .stream()

Files.lines() may be more concise

test/jdk/lib/testlibrary/java/lang/UCDFiles.java line 59:

> 57:         UCD_DIR.resolve("emoji").resolve("emoji-data.txt");
> 58:     public static Path CASEFOLDING =
> 59:         UCD_DIR.resolve("CaseFolding.txt");

Copyright year -> 2025

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

PR Review: https://git.openjdk.org/jdk/pull/26285#pullrequestreview-3017279774
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2205510750
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2205508784
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2205517080
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2205521609

From rriggs at openjdk.org  Mon Jul 14 19:58:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Jul 2025 19:58:40 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
Message-ID: <LWeR7w6C_9o9alZa3ceQDEB2VX_8HuyZpsLG5jqv47U=.e3f2e5ed-6144-410a-a583-519ceace9a6f@github.com>

On Tue, 1 Jul 2025 17:02:27 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Initial benchmark to capture at least some comparative measures of ImageReader performance.
>> 
>> Current results on my laptop:
>> 
>> Benchmark                                         Mode  Cnt   Score    Error  Units
>> NewImageBenchmark.warmCache_CountAllNodes         avgt    5   0.785 ?  0.140  ms/op
>> NewImageBenchmark.coldStart_CountOnly               ss    5  34.051 ? 17.662  ms/op
>> NewImageBenchmark.coldStart_InitAndCount            ss    5  31.006 ?  9.674  ms/op
>> NewImageBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.752 ?  6.873  ms/op
>> 
>> The upcoming changes to ImageReader should show significant improvements to these results.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment about maintainability.

Looks good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26044#pullrequestreview-3017586022

From sherman at openjdk.org  Mon Jul 14 20:13:06 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 20:13:06 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v3]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <FMXB0H9GZvga0ffJAmCnSKL6uTOaDOc3JS2Ze9Ph6Xg=.bcaf2b51-7a0f-4bc2-8c11-d613dda03116@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

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

  update to address the review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/735bd722..e18d2668

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

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

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

From sherman at openjdk.org  Mon Jul 14 20:40:39 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Mon, 14 Jul 2025 20:40:39 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v2]
In-Reply-To: <AZoyQaqBTkKTCt1R05DWBsFQXyYJJ87VoEn4djB8JfM=.2afebbe4-23fc-42e7-b4d1-ab1ab62fcb8d@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <9h1T1edYRoTT3v5CPkY9DN9Lq0bSnDoU8VtK2xn4sIA=.9b57eb79-b59e-4b59-a2ed-94b68735c04f@github.com>
 <AZoyQaqBTkKTCt1R05DWBsFQXyYJJ87VoEn4djB8JfM=.2afebbe4-23fc-42e7-b4d1-ab1ab62fcb8d@github.com>
Message-ID: <NsQ2d3VOrQtdAfPVmnfDrrz1LOqnPPy4uflMRCbCrIg=.2e14a2be-79fc-4e47-91b9-a0afa38322d6@github.com>

On Mon, 14 Jul 2025 18:10:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good. Thanks for adding case folding support which is long overdue ? Since this is adding a new support for casefolding for character class ranges, I think CSR and a release note should be considered.

Thanks for the review. Arguably, the change I made years ago to support Level 1 + RL2.1/2 already implies that character class ranges should conform to RL1.5 ? just like other constructs (back-ref, slice, single and property) So it might be reasonable to categorize this as "just" a pure bug fix.

That said, it is a behavioral change, and I?m happy to go through the CSR and release note process if strongly preferred. ?

My initial thought was to defer the CSR until we fully switch to a case-folding-mapping?based implementation (replacing the current toUpperCase/toLowerCase logic), at which point we could also update the javadoc to explicitly document the behavior of each construct, as RL1.5 recommends/suggests.

But if we prefer to align all of that now with this fix, I?m fine doing it together.

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

PR Comment: https://git.openjdk.org/jdk/pull/26285#issuecomment-3070905666

From naoto at openjdk.org  Mon Jul 14 23:07:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Jul 2025 23:07:38 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v3]
In-Reply-To: <FMXB0H9GZvga0ffJAmCnSKL6uTOaDOc3JS2Ze9Ph6Xg=.bcaf2b51-7a0f-4bc2-8c11-d613dda03116@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <FMXB0H9GZvga0ffJAmCnSKL6uTOaDOc3JS2Ze9Ph6Xg=.bcaf2b51-7a0f-4bc2-8c11-d613dda03116@github.com>
Message-ID: <8xXhxlxCAZZxhZ4fzXjOY797duMUpixmRB6mtS_pPUg=.c848f4b9-59e6-4f5e-a6c7-4254b2ee253c@github.com>

On Mon, 14 Jul 2025 20:13:06 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to address the review comments

Changes look good to me. 
As to the CSR, it seems ok without it if this is a pure bug fix.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26285#pullrequestreview-3018037051

From sherman at openjdk.org  Tue Jul 15 00:32:22 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 00:32:22 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v4]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <fILvArbLjSHximeExPfy_DQcWKxiNIriOhKo2NVPZ6o=.522d4980-3496-4a87-a6e7-6d62e03b1104@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

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

  update and add more test cases, and fix a test failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/e18d2668..c2afc42c

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

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

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

From vyazici at openjdk.org  Tue Jul 15 10:02:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 10:02:29 GMT
Subject: RFR: 8362244: Devkit's Oracle Linux base OS keyword is incorrectly
 documented
Message-ID: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>

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

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

Commit messages:
 - Fix OL-related base OS keywords in Devkit docs

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

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

From sherman at openjdk.org  Tue Jul 15 15:11:07 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 15:11:07 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v5]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

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

  improve the lookup logic and test case for +00df

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/c2afc42c..b85f581f

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

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

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

From sherman at openjdk.org  Tue Jul 15 15:18:54 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 15:18:54 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v5]
In-Reply-To: <6AFn-UzXqb_oY_XGpadyiepteLDrlHJsSqZfXrybPug=.c8454bbe-15df-463a-8e6c-53022ece337b@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <KkZbNbSXZYZ22wG-u_Qgzafv-SxHfITuIq7lNk4RFNg=.a5a9e5b6-c1a7-4e7f-983f-919fea7b97be@github.com>
 <6AFn-UzXqb_oY_XGpadyiepteLDrlHJsSqZfXrybPug=.c8454bbe-15df-463a-8e6c-53022ece337b@github.com>
Message-ID: <UxvyQqURlW9KqVg5vxbMfWRCht3dW63nOWChVDmZn6o=.55cc30b8-84e4-4fca-9a7a-9caf42bf4ea6@github.com>

On Mon, 14 Jul 2025 07:28:09 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/regex/CaseFolding.java.template line 99:
>> 
>>> 97:      */
>>> 98:     public static int[] getClassRangeClosingCharacters(int start, int end) {
>>> 99:         int[] expanded = new int[expanded_casefolding.size()];
>> 
>> Can be `Math.min(expanded_casefolding.size(), end - start)` in case the table grows large, and update the `off < expanded.length` check below too.
>
> The table itself probably isn't going to grow significantly anytime soon, and we?ll likely have enough time to adjust if CaseFolding.txt does get substantially bigger.
> 
> That said, I probably should consider reversing the lookup logic: instead of iterating through [start, end], we could iterate over the expansion table and check whether any of its code points fall within the input range, at least when the range size is larger than the size of the table, kinda O(n) vs O(1)-ish.

updated the lookup logic as discussed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2207809731

From matthias.baesken at sap.com  Tue Jul 15 15:30:04 2025
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 15 Jul 2025 15:30:04 +0000
Subject: malloc/calloc return value NULL check
In-Reply-To: <CAA-vtUzS1gBjH6=EFvjGJU6zLpWZoUzLda=qzN8t=NSuJMt9qw@mail.gmail.com>
References: <AM9PR02MB6770B34C68E9C8DDC337A80F934BA@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <CAA-vtUzS1gBjH6=EFvjGJU6zLpWZoUzLda=qzN8t=NSuJMt9qw@mail.gmail.com>
Message-ID: <AM9PR02MB67707403BECF665AE97D36359357A@AM9PR02MB6770.eurprd02.prod.outlook.com>

Regarding calloc ? checking   ,

jdk.incubator.vector/unix/native/libsleef

seems to have quite a lot  of callocs without a NULL check afterwards , but afaik it is  3rd party coding so we will probably not touch it.


For sunFont.c  I see no direct handling  after calloc in the C code  :

java.desktop/share/native/libfontmanager/sunFont.c-67- */
java.desktop/share/native/libfontmanager/sunFont.c-68-JNIEXPORT jlong JNICALL Java_sun_font_NullFontScaler_getGlyphImage
java.desktop/share/native/libfontmanager/sunFont.c-69-  (JNIEnv *env, jobject scaler, jlong pContext, jint glyphCode) {
java.desktop/share/native/libfontmanager/sunFont.c:70:    void *nullscaler = calloc(1, sizeof(GlyphInfo));
java.desktop/share/native/libfontmanager/sunFont.c-71-    return ptr_to_jlong(nullscaler);
java.desktop/share/native/libfontmanager/sunFont.c-72-}
java.desktop/share/native/libfontmanager/sunFont.c-73-
--
java.desktop/share/native/libfontmanager/sunFont.c-303-JNIEXPORT jlong JNICALL
java.desktop/share/native/libfontmanager/sunFont.c-304-Java_sun_font_StrikeCache_getInvisibleGlyphPtr(JNIEnv *env, jclass cls) {
java.desktop/share/native/libfontmanager/sunFont.c-305-
java.desktop/share/native/libfontmanager/sunFont.c:306:    GlyphInfo *info = (GlyphInfo*) calloc(1, sizeof(GlyphInfo));
java.desktop/share/native/libfontmanager/sunFont.c-307-    return (jlong)(uintptr_t)info; /* invisible glyph */
java.desktop/share/native/libfontmanager/sunFont.c-308-}


(but in the Java coding  calling this,  we seem to have some special  checks for 0, so maybe it is fine)


Here

java.base/windows/native/libjli/java_md.c:951:    appArgIdx = calloc(argc, sizeof(int));
java.base/windows/native/libjli/java_md.c-952-    for (i = idx, j = 0; i < stdargc; i++) {
java.base/windows/native/libjli/java_md.c-953-        if (isTool) { // filter -J used by tools to pass JVM options
java.base/windows/native/libjli/java_md.c-954-            arg = stdargs[i].arg;

we seem to miss a check, should I open a JBS issue ?


Best regards, Matthias


From: Thomas St?fe <thomas.stuefe at gmail.com>
Sent: Friday, 11 July 2025 18:19
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: build-dev at openjdk.org
Subject: Re: malloc/calloc return value NULL check

Absolutely, yes.

The larger the allocated size, the more important. Linux kernel, by default, only protects a small area against NULL accesses; depending on distro, 4KB or 64 (?) KB. And the JVM, at various places, allocates in low-area ranges. So accessing NULL+<large offset> can actually land you at a valid unrelated address instead of faulting.

/Thomas

On Fri, Jul 11, 2025 at 2:57?PM Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>> wrote:
Hi, when playing around with the  GCC static analyzer  ( https://developers.redhat.com/articles/2022/04/12/state-static-analysis-gcc-12-compiler )   I noticed
a lot of complaints about  missing  NULL checks of  malloc/calloc  return values in the code base.

While we check these return values for NULL at a lot of places in the codebase,  it is not done always.
Should we do it always  (except 3rd party code probably where we do not want to have large diffs to upstream) ?

Or is it considered not important enough  to do it always?

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

From naoto at openjdk.org  Tue Jul 15 16:37:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Jul 2025 16:37:43 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v5]
In-Reply-To: <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>
Message-ID: <25jigXcio1o-HB3vf2ZMDBysoPU9whhSOgKZWnMrmd0=.575c1708-5960-441c-a109-1bceb88568b1@github.com>

On Tue, 15 Jul 2025 15:11:07 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve the lookup logic and test case for +00df

Updates look good to me.

test/jdk/java/util/regex/CaseFoldingTest.java line 51:

> 49:         var excluded = Set.of(
> 50:             // these 'S' characters failed for known reason. they don't map to their
> 51:             // fording form with toUpperCase or toLowerCase, only map with case-folding.

nit: fording -> folding

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

PR Review: https://git.openjdk.org/jdk/pull/26285#pullrequestreview-3021193767
PR Review Comment: https://git.openjdk.org/jdk/pull/26285#discussion_r2207985998

From mikael at openjdk.org  Tue Jul 15 16:52:48 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 15 Jul 2025 16:52:48 GMT
Subject: RFR: 8362244: Devkit's Oracle Linux base OS keyword is incorrectly
 documented
In-Reply-To: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
References: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
Message-ID: <k_8q7mzMVtT1BxjEOQrNPr7OEuZPj7_dymNNNKpnWg4=.2e6d1902-0c92-40fa-878a-aa6f380f69f8@github.com>

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

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

You also need to regenerate the corresponding building.html using the `update-build-docs` make target

doc/building.md line 1289:

> 1287: 
> 1288: `BASE_OS` must be one of `OL` for Oracle Enterprise Linux or `Fedora` (if
> 1289: not specified `OL` will be the default). If the base OS is `Fedora` the

Ever so slightly unrelated to your change, but perhaps worth fixing at the same time, even if it means widening the scope of the issue a bit:

There is no default, so suggest dropping the parenthesis part.

doc/building.md line 1291:

> 1289: not specified `OL` will be the default). If the base OS is `Fedora` the
> 1290: corresponding Fedora release can be specified with the help of the
> 1291: `BASE_OS_VERSION` option (with `27` as default version). If the build is

Also unrelated but maybe worth fixing: the default Fedora version is 41 nowadays.

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

PR Review: https://git.openjdk.org/jdk/pull/26311#pullrequestreview-3021243737
PR Review Comment: https://git.openjdk.org/jdk/pull/26311#discussion_r2208015960
PR Review Comment: https://git.openjdk.org/jdk/pull/26311#discussion_r2208016509

From sherman at openjdk.org  Tue Jul 15 16:56:44 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 16:56:44 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v5]
In-Reply-To: <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <jdAdeVsvHk2gdpu036xHSS5ccjw2l9lCgmTin-_0e8s=.2c9c8b1d-904d-4fc9-939d-723499c1392f@github.com>
Message-ID: <eOnRe8KERa_l5lJTa1N6awGQ4AG4_qglLL6yBbM3Vy8=.6e58d464-a3c2-48fd-ba69-50758b36cc0a@github.com>

On Tue, 15 Jul 2025 15:11:07 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve the lookup logic and test case for +00df

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26285#issuecomment-3074413884

From sherman at openjdk.org  Tue Jul 15 17:47:29 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 17:47:29 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v6]
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

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

  update to fix the typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26285/files
  - new: https://git.openjdk.org/jdk/pull/26285/files/b85f581f..a090888f

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

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

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

From naoto at openjdk.org  Tue Jul 15 17:47:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Jul 2025 17:47:30 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v6]
In-Reply-To: <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>
Message-ID: <AX9t_TZdtI02sf6-86bGPTZEmws3Oq1Nk_YovUYkAo8=.19cc69de-1703-4ca8-abd2-5514c57df6af@github.com>

On Tue, 15 Jul 2025 17:44:00 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to fix the typo

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26285#pullrequestreview-3021537588

From sherman at openjdk.org  Tue Jul 15 17:59:47 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 17:59:47 GMT
Subject: RFR: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char [v6]
In-Reply-To: <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
 <5E6oBo3DXqhtFDuwQJTinQxlb0J14QjaXxbKvj5JK0Q=.64180f86-6b61-4383-8f5a-dfb71d1cbd8d@github.com>
Message-ID: <xCTA4BbJR5c3eiy7XH3SJ_aKMXBvH6QTfJz_3asx49U=.b2cb538c-abb6-44db-89aa-80ba4fada9fb@github.com>

On Tue, 15 Jul 2025 17:47:29 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>> 
>> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
>> 
>> **RL1.5 states**: 
>> 
>> To meet this requirement, an implementation that supports case-sensitive matching should
>> 
>>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>>     2. Specify which character properties or constructs are closed under the matching.
>> 
>> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
>> 
>>     1. back-refs
>>     2. string slices (sequences)
>>     3. single character,
>>     4. character families (Unicode Properties ...), and
>>     5. character class ranges
>> 
>> **Note**: Single characters and families may appear independently or within a character class.
>> 
>> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
>> 
>> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
>> 
>> For example:
>> 
>> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
>> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
>> 
>> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
>> 
>> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
>> 
>> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
>> vs
>> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
>> 
>> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
>> 
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
>> perl -C -e 'print "S" =~ /[\x{017f}-\x{0...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to fix the typo

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26285#issuecomment-3074710596

From sherman at openjdk.org  Tue Jul 15 17:59:50 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 15 Jul 2025 17:59:50 GMT
Subject: Integrated: 8360459: UNICODE_CASE and character class with non-ASCII
 range does not match ASCII char
In-Reply-To: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
References: <GxxCr3spqAk1sG0AcDNQw1rJkZ8HJxVA-7w1kgK1i9s=.433d0a19-3531-4f33-a4ce-03afeddb4b52@github.com>
Message-ID: <14NDWi0xfcZsPdfzJDeupxOHKnKJVUJ6tl4jphrJT_s=.29adb663-fc33-4b19-91c1-a264ad2288c5@github.com>

On Mon, 14 Jul 2025 04:53:13 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> Regex class should conform to **_Level 1_** of [Unicode Technical Standard #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
> 
> This PR primarily addresses conformance with RL1.5: Simple Loose Matches, which requires that simple case folding be applied to literals and (optionally) to character classes. When applied to character classes, each class is expected to be closed under simple case folding. See the standard for a detailed explanation of what it means for a class to be ?**_closed_**.?
> 
> **RL1.5 states**: 
> 
> To meet this requirement, an implementation that supports case-sensitive matching should
> 
>     1. Provide at least the simple, default Unicode case-insensitive matching, and
>     2. Specify which character properties or constructs are closed under the matching.
> 
> **In the Pattern implementation**, 5 types of constructs may be affected by case sensitivity:
> 
>     1. back-refs
>     2. string slices (sequences)
>     3. single character,
>     4. character families (Unicode Properties ...), and
>     5. character class ranges
> 
> **Note**: Single characters and families may appear independently or within a character class.
> 
> For case-insensitive (loose) matching, the implementation already applies Character.toUpperCase() and Character.toLowerCase() to **both the pattern and the input string** for back-refs, slices, and single characters. This effectively makes these constructs closed under case folding.
> 
> This has been verified in the newly added test case **_test/jdk/java/util/regex/CaseFoldingTest.java_**.
> 
> For example:
> 
> Pattern.compile("(?ui)\u017f").matcher("S").matches().      => true
> Pattern.compile("(?ui)[\u017f]").matcher("S").matches()    => true
> 
> The character properties (families)  are not "closed" and should remain unchanged. This is acceptable per RL1.5, if the  behavior is clearly specified (TBD: update javadoc to reflect this).
> 
> **Current Non-Conformance: Character Class Ranges**, as reported in the original bug report.
> 
> Pattern.compile("(?ui)[\u017f-\u017f]").matcher("S").matches()  => false
> vs
> Pattern.compile("(?ui)[S-S]").matcher("\u017f").matches().         => true
> 
> vs Perl. (Perl also claims to support the Unicode's loose match with it it's "i" modifier)
> 
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/ ? "true\n" : "false\n"'.  => false
> perl -C -e 'print "S" =~ /[\x{017f}-\x{017f}]/**_i_** ? "true\n" : "false\n"'. => **_true_**
> 
> The root issue is that the ran...

This pull request has now been integrated.

Changeset: 401af27b
Author:    Xueming Shen <sherman at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/401af27b9dbc701eb48e5bc685d3ad058e0de3bc
Stats:     2084 lines in 9 files changed: 2079 ins; 0 del; 5 mod

8360459: UNICODE_CASE and character class with non-ASCII range does not match ASCII char

Reviewed-by: naoto

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

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

From vyazici at openjdk.org  Tue Jul 15 18:19:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 18:19:26 GMT
Subject: RFR: 8362244: Devkit's Oracle Linux base OS keyword is incorrectly
 documented [v2]
In-Reply-To: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
References: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
Message-ID: <sA9ms-oeIY-VcGpTHsaKPeobgc_Fs3js_VrOAj_z43A=.cc62ba98-c8e3-400b-8887-9805b93d5df4@github.com>

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

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

  Apply review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26311/files
  - new: https://git.openjdk.org/jdk/pull/26311/files/d267739d..0d85899a

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

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

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

From vyazici at openjdk.org  Tue Jul 15 18:19:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 18:19:26 GMT
Subject: RFR: 8362244: Devkit's Oracle Linux base OS keyword is incorrectly
 documented [v2]
In-Reply-To: <k_8q7mzMVtT1BxjEOQrNPr7OEuZPj7_dymNNNKpnWg4=.2e6d1902-0c92-40fa-878a-aa6f380f69f8@github.com>
References: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
 <k_8q7mzMVtT1BxjEOQrNPr7OEuZPj7_dymNNNKpnWg4=.2e6d1902-0c92-40fa-878a-aa6f380f69f8@github.com>
Message-ID: <7SZ8qbfkmhrJQitYh0j0S6jRaKTYT55KqG8bdkSWNOs=.f62e7e4a-16c7-4889-aaba-3913edf7223c@github.com>

On Tue, 15 Jul 2025 16:46:24 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback
>
> doc/building.md line 1289:
> 
>> 1287: 
>> 1288: `BASE_OS` must be one of `OL` for Oracle Enterprise Linux or `Fedora` (if
>> 1289: not specified `OL` will be the default). If the base OS is `Fedora` the
> 
> Ever so slightly unrelated to your change, but perhaps worth fixing at the same time, even if it means widening the scope of the issue a bit:
> 
> There is no default, so suggest dropping the parenthesis part.

Removed in 0d85899ae1a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26311#discussion_r2208283263

From vyazici at openjdk.org  Tue Jul 15 18:22:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 15 Jul 2025 18:22:48 GMT
Subject: RFR: 8362244: Devkit's Oracle Linux base OS keyword is incorrectly
 documented [v2]
In-Reply-To: <k_8q7mzMVtT1BxjEOQrNPr7OEuZPj7_dymNNNKpnWg4=.2e6d1902-0c92-40fa-878a-aa6f380f69f8@github.com>
References: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
 <k_8q7mzMVtT1BxjEOQrNPr7OEuZPj7_dymNNNKpnWg4=.2e6d1902-0c92-40fa-878a-aa6f380f69f8@github.com>
Message-ID: <pp5iAy0b74-eRGxGKVUX4c6pYbFox3pquL9VWlnLdRg=.7d1bb9e8-e6e6-490f-9a31-c7c1036f1d8a@github.com>

On Tue, 15 Jul 2025 16:46:44 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review feedback
>
> doc/building.md line 1291:
> 
>> 1289: not specified `OL` will be the default). If the base OS is `Fedora` the
>> 1290: corresponding Fedora release can be specified with the help of the
>> 1291: `BASE_OS_VERSION` option (with `27` as default version). If the build is
> 
> Also unrelated but maybe worth fixing: the default Fedora version is 41 nowadays.

In 0d85899ae1a, I've removed the entire `(with ... as default version)` snippet ? I doubt if it is worth the effort of trying to keep up with that variable, i.e., the Fedora version. We neither share it for OL. Please let me know if you agree or disagree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26311#discussion_r2208293042

From duke at openjdk.org  Tue Jul 15 21:29:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 15 Jul 2025 21:29:41 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
Message-ID: <Jgc8MwUte58wkGpNFe9kLavUVHPUXKqpWOmmFvGIR3o=.cb9db67b-2c87-4894-b0c9-21eb4d37d1be@github.com>

On Tue, 1 Jul 2025 17:02:27 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Initial benchmark to capture at least some comparative measures of ImageReader performance.
>> 
>> Current results on my laptop:
>> 
>> Benchmark                                         Mode  Cnt   Score    Error  Units
>> NewImageBenchmark.warmCache_CountAllNodes         avgt    5   0.785 ?  0.140  ms/op
>> NewImageBenchmark.coldStart_CountOnly               ss    5  34.051 ? 17.662  ms/op
>> NewImageBenchmark.coldStart_InitAndCount            ss    5  31.006 ?  9.674  ms/op
>> NewImageBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.752 ?  6.873  ms/op
>> 
>> The upcoming changes to ImageReader should show significant improvements to these results.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment about maintainability.

Oddly while the status at the bottom of the conversation says it has "2 approvals", the tickbox:


Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author


is not checked. I can try to integrate, but it might not work.

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

PR Comment: https://git.openjdk.org/jdk/pull/26044#issuecomment-3075753460

From alanb at openjdk.org  Wed Jul 16 06:05:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Jul 2025 06:05:39 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v3]
In-Reply-To: <E4dW0zQJNkVozaAP9rjlBDv-wTEtRKMl0OotVJY-9Tg=.d96625fd-17be-4418-96ad-6de5746ea9b7@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
 <M2qvXA4FkPbt7awGXF1OyvFYP30fgDpvqws5Vm7jJwc=.6a1d2fd4-0b56-4b04-be2f-779bdbec35e6@github.com>
 <E4dW0zQJNkVozaAP9rjlBDv-wTEtRKMl0OotVJY-9Tg=.d96625fd-17be-4418-96ad-6de5746ea9b7@github.com>
Message-ID: <wvZd3CoYrWXVH3oxRnrShgse8MQFTXdVlI0nXML1dbY=.a7a23b3c-e9d9-42fb-9248-4271b79d1785@github.com>

On Tue, 1 Jul 2025 16:50:09 GMT, David Beaumont <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 230:
>> 
>>> 228:     // Created by running "java -verbose:class", throwing away anonymous inner
>>> 229:     // classes and anything without a reliable name, and grouping by the stated
>>> 230:     // source. It's not perfect, but it's representative.
>> 
>> I don't think this is maintainable. How useful (or not) is this benchmark if the names of all the internal classes (that will change from release to release) are dropped from this?
>
> Debatable. It's obviously going to scale any results somewhat based on the size of the resources and number of classes. It's kind nice to see "this change removes at least N micro/milli seconds of time spent" since that's a minimum set of classes we expect to always be needed, so any time saved is a lower bound.
> 
> I'd say maybe leave it as is for now with a note saying "if this keeps breaking, make the list less fragile".
> I'm also assuming this is only run manually, and not a part of any CI pipeline ... so please let me know if I'm wrong about that.

lib/classlist is used to generate the AOT archive, I wonder if a `@Setup` could be used to consume that to create the INIT_CLASSES.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2209331471

From duke at openjdk.org  Wed Jul 16 12:03:43 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Jul 2025 12:03:43 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v3]
In-Reply-To: <wvZd3CoYrWXVH3oxRnrShgse8MQFTXdVlI0nXML1dbY=.a7a23b3c-e9d9-42fb-9248-4271b79d1785@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
 <M2qvXA4FkPbt7awGXF1OyvFYP30fgDpvqws5Vm7jJwc=.6a1d2fd4-0b56-4b04-be2f-779bdbec35e6@github.com>
 <E4dW0zQJNkVozaAP9rjlBDv-wTEtRKMl0OotVJY-9Tg=.d96625fd-17be-4418-96ad-6de5746ea9b7@github.com>
 <wvZd3CoYrWXVH3oxRnrShgse8MQFTXdVlI0nXML1dbY=.a7a23b3c-e9d9-42fb-9248-4271b79d1785@github.com>
Message-ID: <eZ9krxtY-kK_m_CVUBJw4MTZsdyAqQD93XTIjSR836A=.8eb895a7-45fc-4d9c-af08-57ce95831ce5@github.com>

On Wed, 16 Jul 2025 06:03:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Debatable. It's obviously going to scale any results somewhat based on the size of the resources and number of classes. It's kind nice to see "this change removes at least N micro/milli seconds of time spent" since that's a minimum set of classes we expect to always be needed, so any time saved is a lower bound.
>> 
>> I'd say maybe leave it as is for now with a note saying "if this keeps breaking, make the list less fragile".
>> I'm also assuming this is only run manually, and not a part of any CI pipeline ... so please let me know if I'm wrong about that.
>
> lib/classlist is used to generate the AOT archive, I wonder if a `@Setup` could be used to consume that to create the INIT_CLASSES.

I will look at that as a followup action. I'd rather get this in to unblock the main ImageReader refactoring.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2210172307

From sgehwolf at openjdk.org  Wed Jul 16 14:04:40 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 16 Jul 2025 14:04:40 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <Jgc8MwUte58wkGpNFe9kLavUVHPUXKqpWOmmFvGIR3o=.cb9db67b-2c87-4894-b0c9-21eb4d37d1be@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
 <Jgc8MwUte58wkGpNFe9kLavUVHPUXKqpWOmmFvGIR3o=.cb9db67b-2c87-4894-b0c9-21eb4d37d1be@github.com>
Message-ID: <aJrygKMlIXPFhSFDGIwenmdaUr9bgQ1H0tvQ9ZDTTNM=.5d2d1b22-d062-4783-9243-cbe528a9b865@github.com>

On Tue, 15 Jul 2025 21:27:16 GMT, David Beaumont <duke at openjdk.org> wrote:

> Oddly while the status at the bottom of the conversation says it has "2 approvals", the tickbox:
> 
> ```
> Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author
> ```
> 
> is not checked. I can try to integrate, but it might not work.

I believe the review of @magicus no longer counts since he reviewed an old version of the patch. Once he acks again it should work.

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

PR Comment: https://git.openjdk.org/jdk/pull/26044#issuecomment-3078764090

From liach at openjdk.org  Wed Jul 16 14:17:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Jul 2025 14:17:41 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
Message-ID: <o0aNsebj6x73mui6Wlrl32TAjTL8cGfNOnxW4olRcIE=.05427e7a-8247-41ba-8fcf-a783655e0185@github.com>

On Tue, 1 Jul 2025 17:02:27 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Initial benchmark to capture at least some comparative measures of ImageReader performance.
>> 
>> Current results on my laptop:
>> 
>> Benchmark                                         Mode  Cnt   Score    Error  Units
>> NewImageBenchmark.warmCache_CountAllNodes         avgt    5   0.785 ?  0.140  ms/op
>> NewImageBenchmark.coldStart_CountOnly               ss    5  34.051 ? 17.662  ms/op
>> NewImageBenchmark.coldStart_InitAndCount            ss    5  31.006 ?  9.674  ms/op
>> NewImageBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.752 ?  6.873  ms/op
>> 
>> The upcoming changes to ImageReader should show significant improvements to these results.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment about maintainability.

Looks reasonable.

As much as this bench is susceptible to JDK changes, many other benchmarks are similarly not robust. We can wait until we run into errors in the benchmarks.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26044#pullrequestreview-3025247133

From mbaesken at openjdk.org  Wed Jul 16 14:34:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 14:34:41 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <XkGbUGRdFEN2yW2Gl5KVahM0oWX00JkyVuElZ6OvIzs=.f3e3aa53-b7b4-4a1e-9349-6a8012824ffe@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <WSsXLUSlfe-ouwBWIacUatrkGd6Vr_6I-diw7l29058=.4f46c44a-2c78-4b0e-9122-a40ca249fe8a@github.com>
 <XkGbUGRdFEN2yW2Gl5KVahM0oWX00JkyVuElZ6OvIzs=.f3e3aa53-b7b4-4a1e-9349-6a8012824ffe@github.com>
Message-ID: <qNsdyFOt0U02C5qDV059wDJ5LOHUGolbY3PEOp98Cy4=.7d6d35f2-3438-4990-991c-7f4be6d6b334@github.com>

On Wed, 9 Apr 2025 20:34:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > Wait, `LOW` is `-O2`? ? I thought it was like no optimization at all. I'm sooo confused with these levels. So maybe going from `LOW` to `SIZE` will actually lose more optimization than I thought. _sigh_
> 
> -Os is the same as -O2 minus some optimizations that increase footprint.
> 
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
> 
> -O3 mostly adds more serious footprint increasing optimizations like loop unrolling. I've seen a number of warnings that suggest in some cases the larger code can reduce performance, so you may be best off with -O2 or -Os for best performance.


So should we give SIZE opt a try now with JDK26  (for libjdwp) ?
Unfortunately we do not have benchmarks for libjdwp (or are there any?) .
But this has not stopped us from updating compiler versions etc.   ....

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

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

From mbaesken at openjdk.org  Wed Jul 16 14:34:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 14:34:41 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <BVE7SlJ7Ek5rBk3QHLmBLSZLurkn3IbHy6cECNfcf4I=.e0b7f295-36a8-4006-9491-c531d293cab5@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <BVE7SlJ7Ek5rBk3QHLmBLSZLurkn3IbHy6cECNfcf4I=.e0b7f295-36a8-4006-9491-c531d293cab5@github.com>
Message-ID: <11N7SC1bEtYE0Zo-81qS8oJ1HpA1CbuzYRZvIOQGbd4=.4f0c0eb5-7e95-4261-a188-8920eeed483c@github.com>

On Wed, 21 May 2025 09:18:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>  So if you think you want to do this library by library, then do so, and if so keep this PR

A lib by lib approach is probably easier to discuss/review.
Changing all (or most) JDK native libs at once will probably make some people unhappy (and it is harder to oversee everything).

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

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

From liach at openjdk.org  Wed Jul 16 14:36:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Jul 2025 14:36:48 GMT
Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes [v4]
In-Reply-To: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>
Message-ID: <R6Yy3Z5kqYyd2n2Ub6AVhCkVb_p624KWFeUfDDRC3os=.702a22a8-557d-4ab9-9cf1-243ed91cef0d@github.com>

On Tue, 1 Jul 2025 17:02:27 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Initial benchmark to capture at least some comparative measures of ImageReader performance.
>> 
>> Current results on my laptop:
>> 
>> Benchmark                                         Mode  Cnt   Score    Error  Units
>> NewImageBenchmark.warmCache_CountAllNodes         avgt    5   0.785 ?  0.140  ms/op
>> NewImageBenchmark.coldStart_CountOnly               ss    5  34.051 ? 17.662  ms/op
>> NewImageBenchmark.coldStart_InitAndCount            ss    5  31.006 ?  9.674  ms/op
>> NewImageBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.752 ?  6.873  ms/op
>> 
>> The upcoming changes to ImageReader should show significant improvements to these results.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment about maintainability.

Thanks David!

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

PR Comment: https://git.openjdk.org/jdk/pull/26044#issuecomment-3078873326

From duke at openjdk.org  Wed Jul 16 14:36:49 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 16 Jul 2025 14:36:49 GMT
Subject: Integrated: 8361076: Add benchmark for ImageReader in preparation for
 Valhalla changes
In-Reply-To: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
Message-ID: <kLCLEUNGkcR0ZkGSJXrgCzUh2k817bFVxSjo634hrAY=.1641ba7b-b128-4ac2-b404-0b573cd82506@github.com>

On Mon, 30 Jun 2025 12:27:40 GMT, David Beaumont <duke at openjdk.org> wrote:

> Initial benchmark to capture at least some comparative measures of ImageReader performance.
> 
> Current results on my laptop:
> 
> Benchmark                                         Mode  Cnt   Score    Error  Units
> NewImageBenchmark.warmCache_CountAllNodes         avgt    5   0.785 ?  0.140  ms/op
> NewImageBenchmark.coldStart_CountOnly               ss    5  34.051 ? 17.662  ms/op
> NewImageBenchmark.coldStart_InitAndCount            ss    5  31.006 ?  9.674  ms/op
> NewImageBenchmark.coldStart_LoadJavacInitClasses    ss    5   3.752 ?  6.873  ms/op
> 
> The upcoming changes to ImageReader should show significant improvements to these results.

This pull request has now been integrated.

Changeset: 770d2b41
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/770d2b41d13a8a5815735c355187a476eeb9de22
Stats:     1080 lines in 2 files changed: 1080 ins; 0 del; 0 mod

8361076: Add benchmark for ImageReader in preparation for Valhalla changes

Reviewed-by: rriggs, liach, ihse

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

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

From vyazici at openjdk.org  Wed Jul 16 18:52:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 16 Jul 2025 18:52:26 GMT
Subject: RFR: 8362244: Devkit's Oracle Linux base OS keyword is incorrectly
 documented [v3]
In-Reply-To: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
References: <6Guorw8ns5l-546zfI-7dRVud0FY1A4QBGlBWQvA6qc=.c54e534f-af8e-4aa1-bd0a-fca9ddfd666e@github.com>
Message-ID: <aT4-w8qplffs_oNEJaP0VPIY0lJhjoT4oEP_kB14E9U=.820028ff-3c6b-4544-aa32-67d26f82119c@github.com>

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

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

  Update `doc/building.html

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26311/files
  - new: https://git.openjdk.org/jdk/pull/26311/files/0d85899a..18199384

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

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

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

From jpai at openjdk.org  Thu Jul 17 09:10:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Jul 2025 09:10:48 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <Y5KgALU_xIs40qkrtuGTXa6uaoL5jnzFSdfP5j2kad4=.783539e5-73e8-4895-9fb4-5bec92d8524c@github.com>

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

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

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

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

From cjplummer at openjdk.org  Thu Jul 17 20:15:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 17 Jul 2025 20:15:56 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <qNsdyFOt0U02C5qDV059wDJ5LOHUGolbY3PEOp98Cy4=.7d6d35f2-3438-4990-991c-7f4be6d6b334@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <WSsXLUSlfe-ouwBWIacUatrkGd6Vr_6I-diw7l29058=.4f46c44a-2c78-4b0e-9122-a40ca249fe8a@github.com>
 <XkGbUGRdFEN2yW2Gl5KVahM0oWX00JkyVuElZ6OvIzs=.f3e3aa53-b7b4-4a1e-9349-6a8012824ffe@github.com>
 <qNsdyFOt0U02C5qDV059wDJ5LOHUGolbY3PEOp98Cy4=.7d6d35f2-3438-4990-991c-7f4be6d6b334@github.com>
Message-ID: <wTwguHjEsdWTiZzYAAywguieAX9u-M7ZzPpAnHcMucI=.6ceed0c3-d45e-4fb4-9709-b998451831a3@github.com>

On Wed, 16 Jul 2025 14:30:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> So should we give SIZE opt a try now with JDK26 (for libjdwp) ?
> Unfortunately we do not have benchmarks for libjdwp (or are there any?) .
> But this has not stopped us from updating compiler versions etc. ....

I'm still not sure whether or not this is a good idea. For benchmarking, you can try running large test suites like nsk/jdi, but I think you'll find the times vary quite a bit. I'd pay more attention to cpu time than wall clock time.

When debugging libjdwp, I often find that it does quite a bit of inlining of non-trivial functions, even with fastdebug builds. I think for the most part this is done when there is only one call site. Some of this will probably go away with -Os, although I won't miss it since I frequently needs to do builds where I make functions extern instead of static so they are not inlined and stack traces are more accurate.

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

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

From shade at openjdk.org  Fri Jul 18 08:09:32 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 18 Jul 2025 08:09:32 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with infra
 overload better
Message-ID: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>

I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.

This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).

We can bump the retention time a bit to handle this a bit better. 

Additional testing:
 - [ ] GHA

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

Commit messages:
 - Fix

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

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

From stuefe at openjdk.org  Fri Jul 18 08:21:47 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 08:21:47 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
Message-ID: <3fT9J0DszZfHwbQplCo_1Qh0aDwMprrtkhFER9oQxyU=.0e1f28ca-db29-46cd-85e8-50ca63b58719@github.com>

On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.
> 
> This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).
> 
> We can bump the retention time a bit to handle this a bit better. 
> 
> Additional testing:
>  - [ ] GHA

+1

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. 

:-( What tests are those, are they special runs? Or the standard ones?

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

PR Review: https://git.openjdk.org/jdk/pull/26383#pullrequestreview-3032525677
PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3088346479

From shade at openjdk.org  Fri Jul 18 08:24:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 18 Jul 2025 08:24:49 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <3fT9J0DszZfHwbQplCo_1Qh0aDwMprrtkhFER9oQxyU=.0e1f28ca-db29-46cd-85e8-50ca63b58719@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
 <3fT9J0DszZfHwbQplCo_1Qh0aDwMprrtkhFER9oQxyU=.0e1f28ca-db29-46cd-85e8-50ca63b58719@github.com>
Message-ID: <SPiX6drFwVVwwnhbJhKd2pp42ouAtshf6eHAzAsZ-2E=.f03d38b3-aaf4-44d1-8635-022ecccaaf39@github.com>

On Fri, 18 Jul 2025 08:19:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> :-( What tests are those, are they special runs? Or the standard ones?

No, just normal ones. @GoeLin showed me https://github.com/openjdk-bots/jdk21u-dev/actions/runs/16302821665/job/46063676040 this morning, but I see there are others in https://github.com/openjdk-bots/jdk21u-dev/actions/. AFAICS, this is a combination of per-user quota (which hits "shared" openjdk-bots heavily) and the Mac capacity in GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3088375018

From stuefe at openjdk.org  Fri Jul 18 08:48:47 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 08:48:47 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <SPiX6drFwVVwwnhbJhKd2pp42ouAtshf6eHAzAsZ-2E=.f03d38b3-aaf4-44d1-8635-022ecccaaf39@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
 <3fT9J0DszZfHwbQplCo_1Qh0aDwMprrtkhFER9oQxyU=.0e1f28ca-db29-46cd-85e8-50ca63b58719@github.com>
 <SPiX6drFwVVwwnhbJhKd2pp42ouAtshf6eHAzAsZ-2E=.f03d38b3-aaf4-44d1-8635-022ecccaaf39@github.com>
Message-ID: <6NvQS6UP7PVMfHsSef6fb7vqWAtY9p7VcnZBorxNoT8=.ca9228ab-a07a-4585-b5a6-04bf31fa405d@github.com>

On Fri, 18 Jul 2025 08:22:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > :-( What tests are those, are they special runs? Or the standard ones?
> 
> No, just normal ones. @GoeLin showed me https://github.com/openjdk-bots/jdk21u-dev/actions/runs/16302821665/job/46063676040 this morning, but I see there are others in https://github.com/openjdk-bots/jdk21u-dev/actions/. I have a gut feeling that this is a combination of per-user quota (which hits "shared" openjdk-bots heavily) and the Mac capacity in GHA. So it hits `/backport` users more often, than those who use their own personal forks.

yes, makes sense its a quota limit, since none of the individual jobs themselves took that long, but total runtime is still 1d8hrs.

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

PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3088580540

From goetz at openjdk.org  Fri Jul 18 09:35:47 2025
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Fri, 18 Jul 2025 09:35:47 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
Message-ID: <9KRvuNkzqFQz27Q_D2PVDGWwqJDdyrVhC59QXvkmwJc=.bd9b4c1c-2b03-4c11-8e45-9e47318c5100@github.com>

On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.
> 
> This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).
> 
> We can bump the retention time a bit to handle this a bit better. 
> 
> Additional testing:
>  - [ ] GHA

Marked as reviewed by goetz (Reviewer).

Hi,
Sometimes I address many simple test fix backports.  This can easily be 20+ in 2-3 hours. This is probably what saturates the infra and my quota.
In general, I don't await all tests to finish.  On a test change, running all the other tests is pointless.  But if there are failed tests, I look at all of these (tedious!).  Usually, it takes me two working days to get through all the process steps and to push such a change.  But I can't make the 24h deadline, nor do I want to to give at least some time for others to eventually have a look at the backport.

So I really appreciate this change.

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

PR Review: https://git.openjdk.org/jdk/pull/26383#pullrequestreview-3032863381
PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3088798571

From stuefe at openjdk.org  Fri Jul 18 10:27:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 18 Jul 2025 10:27:48 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
Message-ID: <lQih2eP74S9OTvqGle88Ket9McwCuZBBkfz7kZhjvUk=.bbba87f0-e7a6-4a5c-9c38-c2d87feca247@github.com>

On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.
> 
> This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).
> 
> We can bump the retention time a bit to handle this a bit better. 
> 
> Additional testing:
>  - [ ] GHA

BTW, this is one more reason why its important to require backporters to have run the full suite of GHAs in their own fork before fix-requesting.

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

PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3088956988

From shade at openjdk.org  Fri Jul 18 12:22:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 18 Jul 2025 12:22:47 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
Message-ID: <iW0sAE-k2aqF5ZZA6SDSArkxC1pAY6pvdvixRN_hNyA=.16fa1dc2-fb27-4ca8-a4b8-1b425ac51275@github.com>

On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.
> 
> This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).
> 
> We can bump the retention time a bit to handle this a bit better. 
> 
> Additional testing:
>  - [ ] GHA

OK, good. I think we can integrate this. I need a formal approval from someone in build group, like @magicus @erikj79 @TheShermanTanker.

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

PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3089307428

From jwaters at openjdk.org  Mon Jul 21 06:31:39 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 21 Jul 2025 06:31:39 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
Message-ID: <Znve9m9tpcpvlwHn_3CmEpcHuRk2UhL9dJaD6hldzn0=.65afcaa3-7462-4986-9b9b-f7021625df3f@github.com>

On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.
> 
> This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).
> 
> We can bump the retention time a bit to handle this a bit better. 
> 
> Additional testing:
>  - [ ] GHA

Increasing retention days seems ok to me. I will page Magnus to see if he has any objections though.

@magicus Do you have any objections?

Off note: Sorry for taking so long to see this. I was away for quite a while due to personal reasons.

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26383#pullrequestreview-3036726877
PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3095410880
PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3095412033

From clanger at openjdk.org  Mon Jul 21 08:20:42 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 21 Jul 2025 08:20:42 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
Message-ID: <LFV2A_fry6H_V6feXVbyt-JKp97irqyEdFBQWbbtMes=.52bbb207-2829-4ec1-a7c4-26cf99c4ff04@github.com>

On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.
> 
> This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).
> 
> We can bump the retention time a bit to handle this a bit better. 
> 
> Additional testing:
>  - [x] GHA

Looks good to me. If we see issues with that, I guess we can modify the value any time again.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26383#pullrequestreview-3037015539

From shade at openjdk.org  Mon Jul 21 09:24:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Jul 2025 09:24:46 GMT
Subject: RFR: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
Message-ID: <fxga3dvv1digRTk39cXJbknFxgF0ZqyTmuDBjCaZCxs=.0fe36b8a-b2e6-41a4-8e5f-4bdc36a87e3f@github.com>

On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.
> 
> This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).
> 
> We can bump the retention time a bit to handle this a bit better. 
> 
> Additional testing:
>  - [x] GHA

Thanks! I suspect @magicus is on vacation? Let's not block ourselves here. I am integrating. We can indeed fix/amend this patch later.

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

PR Comment: https://git.openjdk.org/jdk/pull/26383#issuecomment-3095865992

From shade at openjdk.org  Mon Jul 21 09:24:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Jul 2025 09:24:47 GMT
Subject: Integrated: 8362582: GHA: Increase bundle retention time to deal with
 infra overload better
In-Reply-To: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
References: <Ntgov1Thq3aH9bNPI4BkD9JMOyz4durwqP3QEI0MRIY=.e9395f5e-4965-4c26-8962-ea052b559baa@github.com>
Message-ID: <aNEXjgBCsCeVTOB_c9H3MqXzkJkM2xv6yqTmIwHhsoU=.f1433a49-8475-4946-8146-59881823e4bc@github.com>

On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have now seen GHA runs where we spend more than 24 hours for a testing workflow. The practical effect of this is that bundles that we current carry with `retention-days: 1` gets purged before jobs can use them. This then fails the test jobs that e.g. unable to pull jtreg.
> 
> This seems to happen in openjdk-bots -driven backports quite a bit (the run a lots of GHA runs, so they are often at capacity) and with Mac jobs (where the compute capacity is not great).
> 
> We can bump the retention time a bit to handle this a bit better. 
> 
> Additional testing:
>  - [x] GHA

This pull request has now been integrated.

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

8362582: GHA: Increase bundle retention time to deal with infra overload better

Reviewed-by: goetz, jwaters, clanger

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

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

From kcr at openjdk.org  Tue Jul 22 15:00:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 15:00:36 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
Message-ID: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>

This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.

The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.


src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
src/jdk.compiler/share/data/symbols/symbols
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list


I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into 8359760-rm-jsobject
 - Bump copyright year
 - Merge remote-tracking branch 'upstream/master' into 8359760-rm-jsobject
 - 8359760: Remove the jdk.jsobject module

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

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

From kcr at openjdk.org  Tue Jul 22 15:00:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 15:00:36 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <Jy76wevmXN0kbyz2G-gSH2SrK9dfwZadFX2je3roZA0=.79941b87-398d-4812-910e-163520606089@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

@RogerRiggs @AlanBateman Can you review this PR to remove the `jdk.jsobject` module, which was deprecated for removal by PR #20555 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3103204720

From alanb at openjdk.org  Tue Jul 22 15:09:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Jul 2025 15:09:25 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

I did a quick scan and the updates to the conf, the removal, and the test changes look okay. Happy to review the CSR when you have it ready.

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3103254196

From rriggs at openjdk.org  Tue Jul 22 15:18:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 15:18:52 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:

> 303: jdk.jshell.spi
> 304: jdk.jshell.tool
> 305: module:jdk.jsobject

There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
Can it be removed? Unless it causes a test failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2222878346

From ihse at openjdk.org  Tue Jul 22 15:48:50 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 22 Jul 2025 15:48:50 GMT
Subject: RFR: 8361478: GHA: Use MSYS2 from GHA runners
In-Reply-To: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
References: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
Message-ID: <wojrJ3GBO3zg_zNilqwrofrY4f0duWX-BTu72oyyVqg=.ce86cbb2-3f0b-4a5d-9c31-f312bd6f34be@github.com>

On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Installing MSYS2 takes considerable time in our Windows workflows. Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step say it is enough to say `release: false` to use those:
>  https://github.com/msys2/setup-msys2?tab=readme-ov-file#release
> 
> Also bumping the action version to gain access to the actual installed path.
> 
> Additional testing:
>  - [x] GHA

Sorry, on vacation. (I still am, just checking in here) This looks good though.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26156#pullrequestreview-3043692463

From shade at openjdk.org  Tue Jul 22 16:08:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 16:08:12 GMT
Subject: RFR: 8361478: GHA: Use MSYS2 from GHA runners [v2]
In-Reply-To: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
References: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
Message-ID: <IN2T2zqG3Hnige1OQbZc2_ND53gtl-n6j9csnbiQae0=.dd7f1ce4-ff70-488e-bd3d-3fac8cffd81b@github.com>

> Installing MSYS2 takes considerable time in our Windows workflows. Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step say it is enough to say `release: false` to use those:
>  https://github.com/msys2/setup-msys2?tab=readme-ov-file#release
> 
> Also bumping the action version to gain access to the actual installed path.
> 
> Additional 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8361478-gha-msys2
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26156/files
  - new: https://git.openjdk.org/jdk/pull/26156/files/32328a28..f05fd79f

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

  Stats: 33118 lines in 1000 files changed: 20691 ins; 6424 del; 6003 mod
  Patch: https://git.openjdk.org/jdk/pull/26156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26156/head:pull/26156

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

From shade at openjdk.org  Tue Jul 22 16:08:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 22 Jul 2025 16:08:12 GMT
Subject: RFR: 8361478: GHA: Use MSYS2 from GHA runners
In-Reply-To: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
References: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
Message-ID: <l-GfM0By0hzJC3ISSZ4JEMRUeTJ1-M8HD-Jhgqgw61o=.d21c399a-b6e8-4509-a574-9224a4274871@github.com>

On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Installing MSYS2 takes considerable time in our Windows workflows. Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step say it is enough to say `release: false` to use those:
>  https://github.com/msys2/setup-msys2?tab=readme-ov-file#release
> 
> Also bumping the action version to gain access to the actual installed path.
> 
> Additional testing:
>  - [x] GHA

Thanks! I am going to re-merge to confirm that GHA still works, and then integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/26156#issuecomment-3103579135

From kcr at openjdk.org  Tue Jul 22 18:39:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 18:39:53 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>
Message-ID: <4YzUhJJKnuwc6-nZe7m-PHszEBfhGhb4s2YRW-DmTc0=.27cf04dd-69f6-492e-ae6f-5a001740c877@github.com>

On Tue, 22 Jul 2025 15:06:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I did a quick scan and the updates to the conf, the removal, and the test changes look okay. Happy to review the CSR when you have it ready.

Thanks. The CSR is now ready to review: https://bugs.openjdk.org/browse/JDK-8362628

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3104282605

From kcr at openjdk.org  Tue Jul 22 18:47:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 18:47:00 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
Message-ID: <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>

On Tue, 22 Jul 2025 15:13:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:
> 
>> 303: jdk.jshell.spi
>> 304: jdk.jshell.tool
>> 305: module:jdk.jsobject
> 
> There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
> Can it be removed? Unless it causes a test failure.

I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).

https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56


    private static final String externalDocs =
        "https://docs.oracle.com/en/java/javase/17/docs/api";


I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223507650

From rriggs at openjdk.org  Tue Jul 22 18:51:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 18:51:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
Message-ID: <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>

On Tue, 22 Jul 2025 18:44:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:
>> 
>>> 303: jdk.jshell.spi
>>> 304: jdk.jshell.tool
>>> 305: module:jdk.jsobject
>> 
>> There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
>> Can it be removed? Unless it causes a test failure.
>
> I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).
> 
> https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56
> 
> 
>     private static final String externalDocs =
>         "https://docs.oracle.com/en/java/javase/17/docs/api";
> 
> 
> I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?

I ran the test and then removed those lines and the test still passed.
I'd remove them to avoiding leaving a (little) mess behind.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223524163

From kcr at openjdk.org  Tue Jul 22 19:43:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 19:43:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
Message-ID: <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>

On Tue, 22 Jul 2025 18:48:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).
>> 
>> https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56
>> 
>> 
>>     private static final String externalDocs =
>>         "https://docs.oracle.com/en/java/javase/17/docs/api";
>> 
>> 
>> I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?
>
> I ran the test and then removed those lines and the test still passed.
> I'd remove them to avoiding leaving a (little) mess behind.

As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223678605

From kcr at openjdk.org  Tue Jul 22 19:53:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 19:53:39 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

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

  Remove jdk.jsobject from one more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26393/files
  - new: https://git.openjdk.org/jdk/pull/26393/files/e70c702d..2858cd3e

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

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

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

From rriggs at openjdk.org  Tue Jul 22 19:55:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 19:55:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <-GRJ-l0avR6jYVCgrpu6s1wDdNzxpfrpxDFb__T-X8M=.c8d7e16c-cc62-4fd2-a6b0-7d8f2add3871@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

look good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3044678258

From iris at openjdk.org  Tue Jul 22 20:15:56 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 22 Jul 2025 20:15:56 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <riykbCOmZWw8xZyznbpjn_f9Zk1tppnltpXdS3jwfvo=.bdb4180d-d2c1-4bee-85fb-e6df77bfd5d6@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3044742971

From alanb at openjdk.org  Wed Jul 23 05:57:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 05:57:56 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <fbETTwthRh0Si0UEVuXz19SyNsot077gwkVtOJKTnm4=.2c286921-0f84-487b-8133-4d4b3e667963@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3045747196

From alanb at openjdk.org  Wed Jul 23 05:57:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 05:57:57 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
Message-ID: <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>

On Tue, 22 Jul 2025 19:41:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I ran the test and then removed those lines and the test still passed.
>> I'd remove them to avoiding leaving a (little) mess behind.
>
> As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.

@hns Would it be possible to confirm that it's okay to remove this from the doclet tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2224453194

From mbaesken at openjdk.org  Wed Jul 23 12:30:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Jul 2025 12:30:21 GMT
Subject: RFR: 8363910: Avoid tuning for Power10 CPUs on Linux ppc64le when gcc
 < 10 is used
Message-ID: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>

Older gcc version (8, 9) do not support the -mtune=power10 flag. We should set this only when recent gcc versions are used.

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

Commit messages:
 - JDK-8363910

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

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

From mbaesken at openjdk.org  Wed Jul 23 14:37:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Jul 2025 14:37:54 GMT
Subject: RFR: 8363910: Avoid tuning for Power10 CPUs on Linux ppc64le when
 gcc < 10 is used
In-Reply-To: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
References: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
Message-ID: <ASId1Rl8T5NXvS_Bw6v3XRZxfS-Ez_HOcqZZL9j6boE=.74f3af73-4287-4d23-94be-e5e1011a611a@github.com>

On Wed, 23 Jul 2025 12:23:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Older gcc version (8, 9) do not support the -mtune=power10 flag. We should set this only when recent gcc versions are used.

@jerboaa is that what you would like to have ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26442#issuecomment-3108926980

From hannesw at openjdk.org  Wed Jul 23 14:35:59 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 23 Jul 2025 14:35:59 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
Message-ID: <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>

On Wed, 23 Jul 2025 05:55:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.
>
> @hns Would it be possible to confirm that it's okay to remove this from the doclet tests?

The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225804491

From hannesw at openjdk.org  Wed Jul 23 15:25:01 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 23 Jul 2025 15:25:01 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
 <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
Message-ID: <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>

On Wed, 23 Jul 2025 14:33:34 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> @hns Would it be possible to confirm that it's okay to remove this from the doclet tests?
>
> The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.

Maybe my previous comment was a bit unclear. Both options are okay, leaving the entries and removing them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225940174

From kcr at openjdk.org  Wed Jul 23 15:39:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Jul 2025 15:39:58 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
 <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
 <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>
Message-ID: <49XysSSYVTzmKjja4l23jCkIz_gab8_qXX7eSxb2IsE=.1f07ea64-3a1b-49c6-9ef6-5b06e9616ad3@github.com>

On Wed, 23 Jul 2025 15:22:04 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list is for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.
>
> Maybe my previous comment was a bit unclear. Both options are okay, leaving the entries and removing them.

Thanks. In that case, I'll stick with the current state of the PR which removes them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225986752

From duke at openjdk.org  Wed Jul 23 15:42:59 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Jul 2025 15:42:59 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <lZThqhW_oV4kZT0z239m-ztL7l-fENyyolVs3dcnqn0=.80495d5f-2e75-48ea-bc2c-d7030a16d685@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

@kevinrushforth 
Your change (at version 2858cd3e61b51f213db3265beec30d1afedf1906) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3109170206

From kcr at openjdk.org  Wed Jul 23 15:50:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Jul 2025 15:50:05 GMT
Subject: Integrated: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <hx0zS7djImUSZHj8604N2mlfoMh0ecey7l8pmtfy7jQ=.c470ccd7-6b43-48fe-9478-4469b75c62a0@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

This pull request has now been integrated.

Changeset: 594c080b
Author:    Kevin Rushforth <kcr at openjdk.org>
Committer: Iris Clark <iris at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/594c080b2bde81a48ecccda85ac765218fc93856
Stats:     362 lines in 12 files changed: 0 ins; 358 del; 4 mod

8359760: Remove the jdk.jsobject module

Reviewed-by: rriggs, iris, alanb

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

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

From shade at openjdk.org  Wed Jul 23 16:26:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 23 Jul 2025 16:26:05 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian bookworm
Message-ID: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>

I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:

"Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "

We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).

Additional testing:
 - [ ] GHA

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

Commit messages:
 - RISC-V is still on sid
 - Bookworm

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

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

From shade at openjdk.org  Wed Jul 23 16:50:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 23 Jul 2025 16:50:56 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
Message-ID: <rj8mBD0FXlYctLk3VrR_MGyayyGm7mqFQXEedqAlgjM=.492f3426-d838-4ee8-ab1d-226028781386@github.com>

On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:
> 
> "Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "
> 
> We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).
> 
> Additional testing:
>  - [x] GHA cross-compilation jobs

GHA cross-compilation jobs are green. I think we are ready for reviews/integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/26447#issuecomment-3109398018

From shade at openjdk.org  Thu Jul 24 06:02:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 06:02:13 GMT
Subject: Integrated: 8361478: GHA: Use MSYS2 from GHA runners
In-Reply-To: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
References: <MrLugyO4Kso_CTdaMWhNZPZxIC14EpXDfIBAo1gag08=.86733d6c-1b60-4a00-a614-3bb7789ef724@github.com>
Message-ID: <IGU1AIt9_06LAV4BUnykfLHe3Mv_o8-hCHV9W-SC16w=.52ae9fa8-07a4-4211-b5e8-7cebe56b67d0@github.com>

On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Installing MSYS2 takes considerable time in our Windows workflows. Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step say it is enough to say `release: false` to use those:
>  https://github.com/msys2/setup-msys2?tab=readme-ov-file#release
> 
> Also bumping the action version to gain access to the actual installed path.
> 
> Additional testing:
>  - [x] GHA

This pull request has now been integrated.

Changeset: ed9066bd
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed9066bdf48c2d9925aea745951531ebf4af35a8
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8361478: GHA: Use MSYS2 from GHA runners

Reviewed-by: jwaters, ihse

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

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

From shade at openjdk.org  Thu Jul 24 08:31:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 08:31:54 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
Message-ID: <SyjhaLjAuy5OcN0hwRkelquz6gfHIxO09BIzV5A62KI=.31a7dcb0-f6b4-43a4-a0b9-ee8b902073d3@github.com>

On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:
> 
> "Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "
> 
> We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).
> 
> Additional testing:
>  - [x] GHA cross-compilation jobs

I believe we need it in GHA now, as I see only the GHA jobs that have cached sysroot are not failing. This also applies to update releases, @TheRealMDoerr @RealCLanger @jerboaa :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26447#issuecomment-3112545647

From clanger at openjdk.org  Thu Jul 24 08:47:00 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 24 Jul 2025 08:47:00 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
Message-ID: <dviX7M2xaW9KFR2uogbuRzzWkVkbCeB2daJqYsFYPBw=.f0818709-b39d-407e-ba29-42ebe257ae05@github.com>

On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:
> 
> "Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "
> 
> We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).
> 
> Additional testing:
>  - [x] GHA cross-compilation jobs

Makes sense in order to keep all platforms active.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26447#pullrequestreview-3050692591

From stuefe at openjdk.org  Thu Jul 24 12:23:07 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Jul 2025 12:23:07 GMT
Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is
 configured [v3]
In-Reply-To: <ol_VhN8uBzNkgJopJX0QRA4do1WEriXl-aIFadwIYWo=.2ccf71c9-7eae-410f-8fdd-9ef55590bf79@github.com>
References: <jap4-Oa6-OqSdadCY3dvc1rrpdd8sx198wW91pDaWkQ=.e3e3da72-0c88-4c92-958d-14bf1cabee99@github.com>
 <ol_VhN8uBzNkgJopJX0QRA4do1WEriXl-aIFadwIYWo=.2ccf71c9-7eae-410f-8fdd-9ef55590bf79@github.com>
Message-ID: <KcPOvDGXhMnMyCEE3Z9DXjyAaCQzD99JgNq7WzGuFSM=.85b374d7-84e3-44e5-b9c3-6af2d38181a4@github.com>

On Fri, 27 Jun 2025 07:13:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured.
>> 
>> Examples :
>> runtime/signal/TestSigalrm.java
>> runtime/signal/TestSigbus.java
>> 
>> They run into errors like this
>> 
>> 
>>  stdout: [];
>>  stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
>> 
>> 
>> One option would be to avoid running those tests when  asan is enabled.
>> Another option is to avoid the  so called 'link  order check' .
>> https://github.com/google/sanitizers/wiki/addresssanitizerflags
>> 
>> verify_asan_link_order  -  Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Readjust COPYRIGHT year

Saw this too late. I am unsure about this change, because it disables a rather necessary warning. ASAN interposes a number of APIs, e.g. malloc/free. Bad things can happen if that interposition does not cover the full JVM process. 

E.g. you preload library1, which comes before ASAN interposition is in place, so it uses libc malloc. You then load ASAN, then the rest of JVM. Anything loaded after ASAN will route through ASAN's version of malloc/free. So different parts of the process could use different versions of malloc/free. That could be trouble since we don't know whether pointers returned from raw libc malloc are compatible with ASAN's version of free, and vice versa. Even if nothing like that happens, it would quietly disable ASAN for a part of the libjvm, e.g. in case of libjsig for the libjsig.

Unless we fully understand what would happen in these cases, I would not switch off these warning for the full process. Rather just switch off tests on ASAN builds that rely on LD_PRELOAD. We don't have that many (should only be libjsig, no?)

This is just my 5 cents. I think ASAN is really useful, and the bugs @MBaesken already found proves that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25978#issuecomment-3113258471

From mbaesken at openjdk.org  Thu Jul 24 13:42:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Jul 2025 13:42:58 GMT
Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is
 configured [v3]
In-Reply-To: <ol_VhN8uBzNkgJopJX0QRA4do1WEriXl-aIFadwIYWo=.2ccf71c9-7eae-410f-8fdd-9ef55590bf79@github.com>
References: <jap4-Oa6-OqSdadCY3dvc1rrpdd8sx198wW91pDaWkQ=.e3e3da72-0c88-4c92-958d-14bf1cabee99@github.com>
 <ol_VhN8uBzNkgJopJX0QRA4do1WEriXl-aIFadwIYWo=.2ccf71c9-7eae-410f-8fdd-9ef55590bf79@github.com>
Message-ID: <nEhd5KVCkBbqzoiUelf5yZAZe7f7QowaKchDtFMIrbw=.3128e019-d1a9-4b18-b3bc-38421d8d1a48@github.com>

On Fri, 27 Jun 2025 07:13:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a number of :tier3 HS jtreg tests using libjsig. Unfortunately they clash with asan, so it should be avoided to run them if asan is configured.
>> 
>> Examples :
>> runtime/signal/TestSigalrm.java
>> runtime/signal/TestSigbus.java
>> 
>> They run into errors like this
>> 
>> 
>>  stdout: [];
>>  stderr: [==59482==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
>> 
>> 
>> One option would be to avoid running those tests when  asan is enabled.
>> Another option is to avoid the  so called 'link  order check' .
>> https://github.com/google/sanitizers/wiki/addresssanitizerflags
>> 
>> verify_asan_link_order  -  Check position of ASan runtime in library list (needs to be disabled when other library has to be preloaded system-wide)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Readjust COPYRIGHT year

We could also flag the tests with ` @requires "!vm.asan"`   , that would be less intrusive but needs to be done per test .

Probably in practise both approaches work,  for production we do not use ASAN anyways.

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

PR Comment: https://git.openjdk.org/jdk/pull/25978#issuecomment-3113525692

From stuefe at openjdk.org  Thu Jul 24 13:52:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Jul 2025 13:52:58 GMT
Subject: RFR: 8360478: libjsig related tier3 jtreg tests fail when asan is
 configured [v3]
In-Reply-To: <nEhd5KVCkBbqzoiUelf5yZAZe7f7QowaKchDtFMIrbw=.3128e019-d1a9-4b18-b3bc-38421d8d1a48@github.com>
References: <jap4-Oa6-OqSdadCY3dvc1rrpdd8sx198wW91pDaWkQ=.e3e3da72-0c88-4c92-958d-14bf1cabee99@github.com>
 <ol_VhN8uBzNkgJopJX0QRA4do1WEriXl-aIFadwIYWo=.2ccf71c9-7eae-410f-8fdd-9ef55590bf79@github.com>
 <nEhd5KVCkBbqzoiUelf5yZAZe7f7QowaKchDtFMIrbw=.3128e019-d1a9-4b18-b3bc-38421d8d1a48@github.com>
Message-ID: <YMKh0N1gnW7alGVnsRG_Oe04DrrbVj4UND857vj_KeE=.9a43027c-236a-4ed5-a069-13a58fd45844@github.com>

On Thu, 24 Jul 2025 13:40:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We could also flag the tests with ` @requires "!vm.asan"` , that would be less intrusive but needs to be done per test .
> 

I'd be totally fine with that

> Probably in practise both approaches work, for production we do not use ASAN anyways.

Certainly.

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

PR Comment: https://git.openjdk.org/jdk/pull/25978#issuecomment-3113556312

From fgao at openjdk.org  Thu Jul 24 16:08:37 2025
From: fgao at openjdk.org (Fei Gao)
Date: Thu, 24 Jul 2025 16:08:37 GMT
Subject: RFR: 8363063: AArch64: [VectorAPI] sve vector math operations are not
 supported after JDK-8353217
Message-ID: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>

This patch fixes a typo introduced in [JDK-8353217](https://github.com/openjdk/jdk/commit/130b0cdaa6604da47a893e5425547acf3d5253f4), which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw exceptions on 256-bit SVE machines with errors like:
`java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve`.

`test/jdk/jdk/incubator/vector` passed on `256-bit sve` machine, `macos` and `neon` machine.

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

Commit messages:
 - 8363063: AArch64: [VectorAPI] sve vector math operations are not supported after JDK-8353217

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

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

From shade at openjdk.org  Thu Jul 24 16:17:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Jul 2025 16:17:58 GMT
Subject: RFR: 8363063: AArch64: [VectorAPI] sve vector math operations are
 not supported after JDK-8353217
In-Reply-To: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
References: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
Message-ID: <t_TxStpsFDXZdipltY3KrHJQI3L-Xf6nFCFWojMYyyI=.a020d7a3-1da3-47af-88b3-bbdbfc251ee8@github.com>

On Thu, 24 Jul 2025 16:02:41 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in [JDK-8353217](https://github.com/openjdk/jdk/commit/130b0cdaa6604da47a893e5425547acf3d5253f4), which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw exceptions on 256-bit SVE machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve`.
> 
> `test/jdk/jdk/incubator/vector` passed on `256-bit sve` machine, `macos` and `neon` machine.

Oh, nice catch! (I was wondering about those test failures recently too.)

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26465#pullrequestreview-3052333545

From lucy at openjdk.org  Thu Jul 24 16:32:55 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 24 Jul 2025 16:32:55 GMT
Subject: RFR: 8363910: Avoid tuning for Power10 CPUs on Linux ppc64le when
 gcc < 10 is used
In-Reply-To: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
References: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
Message-ID: <lcM7sKyKCrPggjRaqpR9CnZfyBDrf_evjYmjLMP-sHc=.992067fe-1640-46c4-bfdf-075cc798bb68@github.com>

On Wed, 23 Jul 2025 12:23:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Older gcc version (8, 9) do not support the -mtune=power10 flag. We should set this only when recent gcc versions are used.

Just for my understanding:
If `-mtune=power10` is already in the arguments, nothing is changed/added. In any other case (e.g. `-mtune=power11`), the string `-mtune=power8` is added. Is that intended?

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

Changes requested by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26442#pullrequestreview-3052380845

From mbaesken at openjdk.org  Fri Jul 25 07:12:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 25 Jul 2025 07:12:54 GMT
Subject: RFR: 8363910: Avoid tuning for Power10 CPUs on Linux ppc64le when
 gcc < 10 is used
In-Reply-To: <lcM7sKyKCrPggjRaqpR9CnZfyBDrf_evjYmjLMP-sHc=.992067fe-1640-46c4-bfdf-075cc798bb68@github.com>
References: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
 <lcM7sKyKCrPggjRaqpR9CnZfyBDrf_evjYmjLMP-sHc=.992067fe-1640-46c4-bfdf-075cc798bb68@github.com>
Message-ID: <_bZ080ZsMYOAjUHU4gXJ_fG1KkSBlslnk0KKHhIJMH0=.79d7c76b-a018-45a7-854f-89ad464a44cf@github.com>

On Thu, 24 Jul 2025 16:30:08 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Just for my understanding: If `-mtune=power10` is already in the arguments, nothing is changed/added. In any other case (e.g. `-mtune=power11`), the string `-mtune=power8` is added. Is that intended?

We do not set '-mtune=power11'   , just power10 (default for recent gcc versions) and for old ones where it is not supported (like gcc8) now with this change power8.
In case the user brings in own `-mtune=power<x> ` settings via  additional c/cxx flags , it is up to the user to set them at the right place to overwrite the default .

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

PR Comment: https://git.openjdk.org/jdk/pull/26442#issuecomment-3116679724

From aph at openjdk.org  Fri Jul 25 08:11:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 25 Jul 2025 08:11:54 GMT
Subject: RFR: 8363063: AArch64: [VectorAPI] sve vector math operations are
 not supported after JDK-8353217
In-Reply-To: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
References: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
Message-ID: <rjAQ6F_dc2mO3JPVeCF1x-NKuDD4enApyq3M5L_LbUc=.b8a6c746-5aed-497b-b920-ba7de52f853f@github.com>

On Thu, 24 Jul 2025 16:02:41 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in [JDK-8353217](https://github.com/openjdk/jdk/commit/130b0cdaa6604da47a893e5425547acf3d5253f4), which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw exceptions on 256-bit SVE machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve`.
> 
> `test/jdk/jdk/incubator/vector` passed on `256-bit sve` machine, `macos` and `neon` machine.

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26465#pullrequestreview-3054521451

From stuefe at openjdk.org  Fri Jul 25 09:06:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Jul 2025 09:06:54 GMT
Subject: RFR: 8363910: Avoid tuning for Power10 CPUs on Linux ppc64le when
 gcc < 10 is used
In-Reply-To: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
References: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
Message-ID: <JbOlNMC8CTRnxPRIw75baElGrOk2CvAk3ZwqpyA5QmU=.bc572a99-78b9-442b-b8f3-97d4c43f70db@github.com>

On Wed, 23 Jul 2025 12:23:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Older gcc version (8, 9) do not support the -mtune=power10 flag. We should set this only when recent gcc versions are used.

Very good, this helps our CI errors.

/Thomas

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26442#pullrequestreview-3054676966

From mbaesken at openjdk.org  Fri Jul 25 11:37:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 25 Jul 2025 11:37:59 GMT
Subject: Integrated: 8363910: Avoid tuning for Power10 CPUs on Linux ppc64le
 when gcc < 10 is used
In-Reply-To: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
References: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
Message-ID: <VEKrtQRedj-eyhG5HQlyJEyqWH1PjZTQgQQ2KmYT6BU=.ec8e5dba-7f50-4aab-b7b2-a8d026d6e43c@github.com>

On Wed, 23 Jul 2025 12:23:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Older gcc version (8, 9) do not support the -mtune=power10 flag. We should set this only when recent gcc versions are used.

This pull request has now been integrated.

Changeset: 41c94eed
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41c94eed37aad570229ee2c5fb51d9e5d0378a40
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8363910: Avoid tuning for Power10 CPUs on Linux ppc64le when gcc < 10 is used

Reviewed-by: stuefe

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

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

From mbaesken at openjdk.org  Fri Jul 25 11:37:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 25 Jul 2025 11:37:59 GMT
Subject: RFR: 8363910: Avoid tuning for Power10 CPUs on Linux ppc64le when
 gcc < 10 is used
In-Reply-To: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
References: <vodpStetAq6bn0WKWpHM3Omfyf9Bu-k6UitvrHGnAgI=.033d8260-5c31-4f2d-969b-a167eb79d103@github.com>
Message-ID: <zijjBu_Y90erE01crSXYgHWgx9_vllPh1t_ulQYWJMI=.83afcb39-320f-4685-aa67-e9b8376d282a@github.com>

On Wed, 23 Jul 2025 12:23:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Older gcc version (8, 9) do not support the -mtune=power10 flag. We should set this only when recent gcc versions are used.

Thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/26442#issuecomment-3117458965

From fgao at openjdk.org  Mon Jul 28 08:46:58 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 28 Jul 2025 08:46:58 GMT
Subject: RFR: 8363063: AArch64: [VectorAPI] sve vector math operations are
 not supported after JDK-8353217
In-Reply-To: <rjAQ6F_dc2mO3JPVeCF1x-NKuDD4enApyq3M5L_LbUc=.b8a6c746-5aed-497b-b920-ba7de52f853f@github.com>
References: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
 <rjAQ6F_dc2mO3JPVeCF1x-NKuDD4enApyq3M5L_LbUc=.b8a6c746-5aed-497b-b920-ba7de52f853f@github.com>
Message-ID: <te9pAWA5PduhM7d8vF0xCZ8j6AQk7IddDTxLAV-QG-Y=.8a300dd1-34f3-4eff-8f7b-51c9db6071c6@github.com>

On Fri, 25 Jul 2025 08:09:45 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch fixes a typo introduced in [JDK-8353217](https://github.com/openjdk/jdk/commit/130b0cdaa6604da47a893e5425547acf3d5253f4), which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw exceptions on 256-bit SVE machines with errors like:
>> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve`.
>> 
>> `test/jdk/jdk/incubator/vector` passed on `256-bit sve` machine, `macos` and `neon` machine.
>
> Marked as reviewed by aph (Reviewer).

Thanks for your approval @theRealAph @shipilev !

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

PR Comment: https://git.openjdk.org/jdk/pull/26465#issuecomment-3126170216

From fgao at openjdk.org  Mon Jul 28 08:46:59 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 28 Jul 2025 08:46:59 GMT
Subject: Integrated: 8363063: AArch64: [VectorAPI] sve vector math operations
 are not supported after JDK-8353217
In-Reply-To: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
References: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
Message-ID: <DYUax-Dk_tc6s20BLx0T_FDbdD9eJwmNV89UplOP56Y=.9d151970-3261-4f7a-9f7a-44cc94dfe167@github.com>

On Thu, 24 Jul 2025 16:02:41 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch fixes a typo introduced in [JDK-8353217](https://github.com/openjdk/jdk/commit/130b0cdaa6604da47a893e5425547acf3d5253f4), which incorrectly disabled SVE vector math symbols. As a result, some vector math test cases such as `jdk/incubator/vector/Double256VectorTests.java` threw exceptions on 256-bit SVE machines with errors like:
> `java.lang.InternalError: not supported: ACOS Species[double, 4, S_256_BIT] acosdx_u10sve`.
> 
> `test/jdk/jdk/incubator/vector` passed on `256-bit sve` machine, `macos` and `neon` machine.

This pull request has now been integrated.

Changeset: 011de4c8
Author:    Fei Gao <fgao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/011de4c894ed827ee8e15a7cfe400788175e5b2c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8363063: AArch64: [VectorAPI] sve vector math operations are not supported after JDK-8353217

Reviewed-by: shade, aph

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

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

From shade at openjdk.org  Mon Jul 28 09:14:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 09:14:56 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
Message-ID: <5rfbhFccHKzZUG7IGUOpbTpaPSCHRK72kNHZsyhhgA4=.64214e50-0e0e-4102-aa4a-0c7f34f71ee0@github.com>

On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:
> 
> "Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "
> 
> We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).
> 
> Additional testing:
>  - [x] GHA cross-compilation jobs

Thanks! More reviews, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/26447#issuecomment-3116842791

From shade at openjdk.org  Mon Jul 28 09:14:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 09:14:56 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <5rfbhFccHKzZUG7IGUOpbTpaPSCHRK72kNHZsyhhgA4=.64214e50-0e0e-4102-aa4a-0c7f34f71ee0@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
 <5rfbhFccHKzZUG7IGUOpbTpaPSCHRK72kNHZsyhhgA4=.64214e50-0e0e-4102-aa4a-0c7f34f71ee0@github.com>
Message-ID: <BqsKiV29xfrfE0Phj4g6w0_aHoUnFTLNnvq3zu3Wzb0=.54e5f9df-87a5-4be3-b1ce-7f73965871e8@github.com>

On Fri, 25 Jul 2025 08:12:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Thanks! More reviews, please?

Ping :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26447#issuecomment-3126292006

From shade at openjdk.org  Mon Jul 28 09:44:01 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Jul 2025 09:44:01 GMT
Subject: RFR: 8363063: AArch64: [VectorAPI] sve vector math operations are
 not supported after JDK-8353217
In-Reply-To: <te9pAWA5PduhM7d8vF0xCZ8j6AQk7IddDTxLAV-QG-Y=.8a300dd1-34f3-4eff-8f7b-51c9db6071c6@github.com>
References: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
 <rjAQ6F_dc2mO3JPVeCF1x-NKuDD4enApyq3M5L_LbUc=.b8a6c746-5aed-497b-b920-ba7de52f853f@github.com>
 <te9pAWA5PduhM7d8vF0xCZ8j6AQk7IddDTxLAV-QG-Y=.8a300dd1-34f3-4eff-8f7b-51c9db6071c6@github.com>
Message-ID: <YwDvqxVlvobkdIhly6CMmIqQyjldzn180Xr6s3xcWug=.fcacf581-3b50-4d8c-b09b-8497a4c87d84@github.com>

On Mon, 28 Jul 2025 08:43:25 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> Marked as reviewed by aph (Reviewer).
>
> Thanks for your approval @theRealAph @shipilev !

@fg1417 -- want to pull it to `jdk25u`? I think it is not a showstopper for JDK 25 GA, so we can get it into `25.0.1`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26465#issuecomment-3126403543

From aoqi at openjdk.org  Mon Jul 28 10:24:49 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 28 Jul 2025 10:24:49 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng on
 LoongArch64
Message-ID: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>

After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.


#ifndef PNG_LOONGARCH_LSX_OPT
# if defined(__loongarch_sx)
# define PNG_LOONGARCH_LSX_OPT 1
# else
# define PNG_LOONGARCH_LSX_OPT 0
# endif
#endif


Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

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

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

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

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

From fgao at openjdk.org  Mon Jul 28 10:38:58 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 28 Jul 2025 10:38:58 GMT
Subject: RFR: 8363063: AArch64: [VectorAPI] sve vector math operations are
 not supported after JDK-8353217
In-Reply-To: <YwDvqxVlvobkdIhly6CMmIqQyjldzn180Xr6s3xcWug=.fcacf581-3b50-4d8c-b09b-8497a4c87d84@github.com>
References: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
 <rjAQ6F_dc2mO3JPVeCF1x-NKuDD4enApyq3M5L_LbUc=.b8a6c746-5aed-497b-b920-ba7de52f853f@github.com>
 <te9pAWA5PduhM7d8vF0xCZ8j6AQk7IddDTxLAV-QG-Y=.8a300dd1-34f3-4eff-8f7b-51c9db6071c6@github.com>
 <YwDvqxVlvobkdIhly6CMmIqQyjldzn180Xr6s3xcWug=.fcacf581-3b50-4d8c-b09b-8497a4c87d84@github.com>
Message-ID: <sGH0vFPq9KjQPZUeiuOvz7XwuFKBgojdxhUsjmWvX0o=.fe1462ba-1c3d-4898-9657-8abbc2a77b9e@github.com>

On Mon, 28 Jul 2025 09:41:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thanks for your approval @theRealAph @shipilev !
>
> @fg1417 -- want to pull it to `jdk25u`? I think it is not a showstopper for JDK 25 GA, so we can get it into `25.0.1`.

@shipilev thanks for your reminder! I'll backport it to` jdk25u` soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/26465#issuecomment-3126610930

From jpai at openjdk.org  Mon Jul 28 10:45:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 10:45:58 GMT
Subject: RFR: 8363063: AArch64: [VectorAPI] sve vector math operations are
 not supported after JDK-8353217
In-Reply-To: <sGH0vFPq9KjQPZUeiuOvz7XwuFKBgojdxhUsjmWvX0o=.fe1462ba-1c3d-4898-9657-8abbc2a77b9e@github.com>
References: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
 <rjAQ6F_dc2mO3JPVeCF1x-NKuDD4enApyq3M5L_LbUc=.b8a6c746-5aed-497b-b920-ba7de52f853f@github.com>
 <te9pAWA5PduhM7d8vF0xCZ8j6AQk7IddDTxLAV-QG-Y=.8a300dd1-34f3-4eff-8f7b-51c9db6071c6@github.com>
 <YwDvqxVlvobkdIhly6CMmIqQyjldzn180Xr6s3xcWug=.fcacf581-3b50-4d8c-b09b-8497a4c87d84@github.com>
 <sGH0vFPq9KjQPZUeiuOvz7XwuFKBgojdxhUsjmWvX0o=.fe1462ba-1c3d-4898-9657-8abbc2a77b9e@github.com>
Message-ID: <lyxUcTX_7jWh1yMuzzRHSk5xkEWIC20jF5uMuISfcLU=.b0308273-a85e-482c-965e-6f0c6350049f@github.com>

On Mon, 28 Jul 2025 10:36:16 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> @fg1417 -- want to pull it to `jdk25u`? I think it is not a showstopper for JDK 25 GA, so we can get it into `25.0.1`.
>
> @shipilev thanks for your reminder! I'll backport it to` jdk25u` soon.

Hello @fg1417, we see build failures in our CI on linux-aarch64 after this change was integrated. Details are available in https://bugs.openjdk.org/browse/JDK-8364185.

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

PR Comment: https://git.openjdk.org/jdk/pull/26465#issuecomment-3126634312

From jpai at openjdk.org  Mon Jul 28 10:51:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 10:51:43 GMT
Subject: RFR: 8364185: [BACKOUT] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
Message-ID: <UWrADuLmnd34vRNYqPx-cQpeVrLTC3WhsmR8eneU1Vc=.0a88ea1a-d595-42af-9682-14d1d482858e@github.com>

Can I please get a review of this change which backs out the changes done in https://bugs.openjdk.org/browse/JDK-8363063? The linux-aarch64 builds in our CI started failing after the changes in JDK-8363063 were integrated. 

The description in the backout issue https://bugs.openjdk.org/browse/JDK-8364185 has the details about the build failure errors.

The commit in this PR backs out the change (`git revert 011de4c894ed827ee8e15a7cfe400788175e5b2c`). CI jobs are currently in progress to verify that this backout fixes the build failures.

A new REDO issue has been created https://bugs.openjdk.org/browse/JDK-8364184 to redo the original change and address these linux-aarch64 build issues.

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

Commit messages:
 - Revert "8363063: AArch64: [VectorAPI] sve vector math operations are not supported after JDK-8353217"

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

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

From ayang at openjdk.org  Mon Jul 28 10:51:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 28 Jul 2025 10:51:43 GMT
Subject: RFR: 8364185: [BACKOUT] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <UWrADuLmnd34vRNYqPx-cQpeVrLTC3WhsmR8eneU1Vc=.0a88ea1a-d595-42af-9682-14d1d482858e@github.com>
References: <UWrADuLmnd34vRNYqPx-cQpeVrLTC3WhsmR8eneU1Vc=.0a88ea1a-d595-42af-9682-14d1d482858e@github.com>
Message-ID: <OfPBwio5W6uXXaDiTl2-qGCbConnUKbuVGq_B7vBJ-M=.feac7c7a-a3a5-4bf2-adc4-22debf3c3aa2@github.com>

On Mon, 28 Jul 2025 10:40:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which backs out the changes done in https://bugs.openjdk.org/browse/JDK-8363063? The linux-aarch64 builds in our CI started failing after the changes in JDK-8363063 were integrated. 
> 
> The description in the backout issue https://bugs.openjdk.org/browse/JDK-8364185 has the details about the build failure errors.
> 
> The commit in this PR backs out the change (`git revert 011de4c894ed827ee8e15a7cfe400788175e5b2c`). CI jobs are currently in progress to verify that this backout fixes the build failures.
> 
> A new REDO issue has been created https://bugs.openjdk.org/browse/JDK-8364184 to redo the original change and address these linux-aarch64 build issues.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26503#pullrequestreview-3061896714

From jpai at openjdk.org  Mon Jul 28 11:53:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 11:53:57 GMT
Subject: RFR: 8364185: [BACKOUT] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <OfPBwio5W6uXXaDiTl2-qGCbConnUKbuVGq_B7vBJ-M=.feac7c7a-a3a5-4bf2-adc4-22debf3c3aa2@github.com>
References: <UWrADuLmnd34vRNYqPx-cQpeVrLTC3WhsmR8eneU1Vc=.0a88ea1a-d595-42af-9682-14d1d482858e@github.com>
 <OfPBwio5W6uXXaDiTl2-qGCbConnUKbuVGq_B7vBJ-M=.feac7c7a-a3a5-4bf2-adc4-22debf3c3aa2@github.com>
Message-ID: <YyyDFwQVT1NtUsemNkaW8jxCYAFKZbSILMFB9oD6zVc=.bea39b6a-acef-448a-ab61-40bce2cc5160@github.com>

On Mon, 28 Jul 2025 10:46:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Can I please get a review of this change which backs out the changes done in https://bugs.openjdk.org/browse/JDK-8363063? The linux-aarch64 builds in our CI started failing after the changes in JDK-8363063 were integrated. 
>> 
>> The description in the backout issue https://bugs.openjdk.org/browse/JDK-8364185 has the details about the build failure errors.
>> 
>> The commit in this PR backs out the change (`git revert 011de4c894ed827ee8e15a7cfe400788175e5b2c`). CI jobs are currently in progress to verify that this backout fixes the build failures.
>> 
>> A new REDO issue has been created https://bugs.openjdk.org/browse/JDK-8364184 to redo the original change and address these linux-aarch64 build issues.
>
> Marked as reviewed by ayang (Reviewer).

Thank you @albertnetymk for the review. The CI job that I had triggered internally completed successfully without any failures after this backout. I'll go ahead and integrate this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/26503#issuecomment-3126863650

From jpai at openjdk.org  Mon Jul 28 11:53:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 28 Jul 2025 11:53:58 GMT
Subject: Integrated: 8364185: [BACKOUT] AArch64: [VectorAPI] sve vector math
 operations are not supported after JDK-8353217
In-Reply-To: <UWrADuLmnd34vRNYqPx-cQpeVrLTC3WhsmR8eneU1Vc=.0a88ea1a-d595-42af-9682-14d1d482858e@github.com>
References: <UWrADuLmnd34vRNYqPx-cQpeVrLTC3WhsmR8eneU1Vc=.0a88ea1a-d595-42af-9682-14d1d482858e@github.com>
Message-ID: <GazNyVUAuVwCdwf0_LeuJF-dZXLRc1T_MTsaWj3NrR4=.00bc75b1-efeb-47b0-a68b-7a75733fe958@github.com>

On Mon, 28 Jul 2025 10:40:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which backs out the changes done in https://bugs.openjdk.org/browse/JDK-8363063? The linux-aarch64 builds in our CI started failing after the changes in JDK-8363063 were integrated. 
> 
> The description in the backout issue https://bugs.openjdk.org/browse/JDK-8364185 has the details about the build failure errors.
> 
> The commit in this PR backs out the change (`git revert 011de4c894ed827ee8e15a7cfe400788175e5b2c`). CI jobs are currently in progress to verify that this backout fixes the build failures.
> 
> A new REDO issue has been created https://bugs.openjdk.org/browse/JDK-8364184 to redo the original change and address these linux-aarch64 build issues.

This pull request has now been integrated.

Changeset: b7703f79
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b7703f7948039526cb7ca74ed589d6e3a876b6f6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8364185: [BACKOUT] AArch64: [VectorAPI] sve vector math operations are not supported after JDK-8353217

Reviewed-by: ayang

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

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

From fgao at openjdk.org  Mon Jul 28 13:06:03 2025
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 28 Jul 2025 13:06:03 GMT
Subject: RFR: 8363063: AArch64: [VectorAPI] sve vector math operations are
 not supported after JDK-8353217
In-Reply-To: <sGH0vFPq9KjQPZUeiuOvz7XwuFKBgojdxhUsjmWvX0o=.fe1462ba-1c3d-4898-9657-8abbc2a77b9e@github.com>
References: <hNZvwqfSyjfj6nFTOikM-3fmiWZk5qWIAbkSjvot8kA=.dfa57d79-84b3-42a4-832b-53abf4fb1ac3@github.com>
 <rjAQ6F_dc2mO3JPVeCF1x-NKuDD4enApyq3M5L_LbUc=.b8a6c746-5aed-497b-b920-ba7de52f853f@github.com>
 <te9pAWA5PduhM7d8vF0xCZ8j6AQk7IddDTxLAV-QG-Y=.8a300dd1-34f3-4eff-8f7b-51c9db6071c6@github.com>
 <YwDvqxVlvobkdIhly6CMmIqQyjldzn180Xr6s3xcWug=.fcacf581-3b50-4d8c-b09b-8497a4c87d84@github.com>
 <sGH0vFPq9KjQPZUeiuOvz7XwuFKBgojdxhUsjmWvX0o=.fe1462ba-1c3d-4898-9657-8abbc2a77b9e@github.com>
Message-ID: <KYyGeozKx8gL_-7zvP56Nwnl6Af8tgPfmNorAl6BJS0=.025b367e-4eee-448d-a2b0-6975206e0e69@github.com>

On Mon, 28 Jul 2025 10:36:16 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> @fg1417 -- want to pull it to `jdk25u`? I think it is not a showstopper for JDK 25 GA, so we can get it into `25.0.1`.
>
> @shipilev thanks for your reminder! I'll backport it to` jdk25u` soon.

> Hello @fg1417, we see build failures in our CI on linux-aarch64 after this change was integrated. Details are available in https://bugs.openjdk.org/browse/JDK-8364185.

@jaikiran thanks for reporting this. I'll take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/26465#issuecomment-3127153265

From jlahoda at openjdk.org  Mon Jul 28 15:42:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Jul 2025 15:42:54 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v2]
In-Reply-To: <kRmQfEMYYRS3APBZOFrDji7ybQp4BMtc6PRf5xhL_6E=.7642f5e4-bc8f-4292-8ea0-5c8918d9d919@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <rKksQGL878yEnwuqstC_rF08KEQ7_vO60D9ZYTiI-Vg=.e5e824dd-d8e5-432b-a4a9-4f956cf660d0@github.com>
 <kRmQfEMYYRS3APBZOFrDji7ybQp4BMtc6PRf5xhL_6E=.7642f5e4-bc8f-4292-8ea0-5c8918d9d919@github.com>
Message-ID: <A7IkPe5TC0xAT5PLZKnLuU1QpzIMRxQtdR5-_SDU6k8=.d2a79517-aa1a-44ff-b235-e0a69d13b91e@github.com>

On Fri, 25 Jul 2025 14:38:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fixing toString value for flags that have ACC_ overloaded flags.
>>  - Review feedback: marking ACC flags with the @Use annotation, forces split of the TYPE target into CLASS/MODULE/PACKAGE/TYPE_VARIABLE.
>>  - Reflecting review feedback:
>>    - when conflict is detected, the generator fails
>>    - adding runtime checks
>>    - using constants for number of bits
>
> There's a lot to like in this patch. Now flags cannot erroneously overlap, which will give us all javac developers more confidence that we're not stepping into each other toes. Also, by making the mechanism more formally correct, it's easier to see which "holes" we have available (and there's probably quite a lot left).
> 
> The only thing I'm unsure of, as pointed out in the review, is the dynamic checks. I believe that, as far as this PR is concerned, this feels like "scope creep". I think it would be cleaner if this PR only concerned about introducing the machinery. Then maybe we can brainstorm separately on what would be the best way to add some of these checks (but I'm skeptical that we can find anything that doesn't feel like a compromise).
> 
> For instance, another way to do this could be to do another combo test like the tree test, where we compile all the existing tests, and check the validity of all the flags on all the symbols. That's an offline way to make sure that what we do in javac is "sort of" correct, but one that doesn't leak into the code.
> 
> The real fix for this, as we know (and as @archiecobbs commented) is to move away from longs, but that's not what this PR is about.

Thanks @mcimadamore for the review.

I think the build changes are now ready to be reviewed. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26452#issuecomment-3127824873

From liach at openjdk.org  Mon Jul 28 21:16:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 21:16:55 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
Message-ID: <z7mfCWZR-naeyRqaV4Nax0eoWGxfXxipQtzRmjd9828=.229922da-dc67-41d2-96ad-0748b50ccb99@github.com>

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

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

make/langtools/tools/flagsgenerator/FlagsGenerator.java line 64:

> 62:             TypeElement clazz = (TypeElement) trees.getElement(new TreePath(new TreePath(cut), cut.getTypeDecls().get(0)));
> 63:             Map<Integer, List<String>> flag2Names = new TreeMap<>();
> 64:             Map<FlagTarget, Map<Integer, List<String>>> target2FlagBit2Fields = new HashMap<>();

Suggestion:

            Map<FlagTarget, Map<Integer, List<String>>> target2FlagBit2Fields = new EnumMap<>(FlagTarget.class);

make/langtools/tools/flagsgenerator/FlagsGenerator.java line 84:

> 82:                                            .forEach(target -> target2FlagBit2Fields.computeIfAbsent(target, _ -> new HashMap<>())
> 83:                                                                                    .computeIfAbsent(flagBit, _ -> new ArrayList<>())
> 84:                                                                                    .add(flagName));

Instead of a dedicated loop to verify no overlaps, we can make the nested map `Map<Integer, String>` and fail fast whenever we detect a conflict, like:

var oldFlagName = target2FlagBit2Fields.computeIfAbsent(target, _ -> new HashMap<>()).put(flagBit, flagName);
if (oldFlagName != null) {
    // Fail fast code
}

I personally don't see a reason to collect all conflicting fields for a flag if any of these conflicts already causes a failure.

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

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

From shade at openjdk.org  Tue Jul 29 06:47:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Jul 2025 06:47:55 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
Message-ID: <yAeRryzHRwDJvGMb3KQS95x4hQwOLDpIiF_uwsOQs68=.8ee1fa87-793d-4f6d-a052-5d43291dba40@github.com>

On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:
> 
> "Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "
> 
> We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).
> 
> Additional testing:
>  - [x] GHA cross-compilation jobs

Ping? @TheShermanTanker @magicus @erikj79 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26447#issuecomment-3130912275

From jwaters at openjdk.org  Tue Jul 29 07:04:56 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Jul 2025 07:04:56 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
Message-ID: <wop8yjO7Ep_Al6bvYaF5PLQeh_5XZ6OSzN8HTrqyd6M=.893f8c61-5464-41ee-b18a-866c209a44b9@github.com>

On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:
> 
> "Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "
> 
> We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).
> 
> Additional testing:
>  - [x] GHA cross-compilation jobs

Looks good to me

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26447#pullrequestreview-3065831097

From shade at openjdk.org  Tue Jul 29 08:13:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Jul 2025 08:13:59 GMT
Subject: RFR: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
Message-ID: <kHJvig8UineJC58-GuTI17mflxnE95Segi39o-koJiA=.2f472bbc-f645-4c92-bab5-b7400966d75e@github.com>

On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:
> 
> "Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "
> 
> We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).
> 
> Additional testing:
>  - [x] GHA cross-compilation jobs

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26447#issuecomment-3131191862

From shade at openjdk.org  Tue Jul 29 08:14:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Jul 2025 08:14:00 GMT
Subject: Integrated: 8363965: GHA: Switch cross-compiling sysroots to Debian
 bookworm
In-Reply-To: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
References: <xPbxjPtHcJAKT-UvT7mCizD0oo6r6rzrtVDoGlYJoEs=.14ff2467-29fd-436a-becb-fca9fa864cc1@github.com>
Message-ID: <gdDQLVg_Qoy1Fwsn2iwBfdWPz0hQEqAZZ51vKvTTRsc=.05904781-b8ea-493a-9462-db30ec4289ba@github.com>

On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- says:
> 
> "Important: The current LTS version is Debian 11 ("bullseye") and will be supported until August 31st, 2026. Supported architectures in Debian 11 LTS are limited to amd64, i386, arm64 and armhf. Users of other architectures are especially encouraged to upgrade to Debian 12 (''bookworm''). "
> 
> We should consider switching to Debian bookworm for GHA cross-compiling sysroots. Again, Debian wiki: https://wiki.debian.org/DebianBookworm#Architectures -- says all architectures we need are supported. But actually, RISC-V is still only supported with sid. So, we need to be switching only current bullseye to bookworm, leaving sid as sid. This should change as Debian trixie releases in a few weeks, but we cannot wait for this long. Debian trixie update would be handled in [JDK-8363966](https://bugs.openjdk.org/browse/JDK-8363966).
> 
> Additional testing:
>  - [x] GHA cross-compilation jobs

This pull request has now been integrated.

Changeset: 3fe0d29e
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3fe0d29ec3b5b327d633726677ba1809eec27665
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8363965: GHA: Switch cross-compiling sysroots to Debian bookworm

Reviewed-by: clanger, jwaters

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

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

From andrew.m.leonard at ibm.com  Tue Jul 29 15:16:09 2025
From: andrew.m.leonard at ibm.com (Andrew Leonard)
Date: Tue, 29 Jul 2025 15:16:09 +0000
Subject: JDK-8363942: Unable to make images after "make -t"
Message-ID: <IA0PPF8870D55A12B1311A446CEE3A06717CA25A@IA0PPF8870D55A1.namprd15.prod.outlook.com>

Hi,

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

Many thanks
Andrew

Unless otherwise stated above:

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

From prr at openjdk.org  Tue Jul 29 17:29:55 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 29 Jul 2025 17:29:55 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>

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

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

If PNG_LOONGARCH_LSX_OPT is set to 0 it disables all those extra fns
https://github.com/openjdk/jdk/pull/18964/files

So LGTM.

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

Marked as reviewed by prr (Reviewer).

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

From aoqi at openjdk.org  Wed Jul 30 05:20:04 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 30 Jul 2025 05:20:04 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
 <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>
Message-ID: <NFXjSBniq1o_pHDc4JrSG4ugj9pIQFwkidWpYg3o65s=.2142775b-bb7a-4c46-ba5e-dddfd4c89c6b@github.com>

On Tue, 29 Jul 2025 17:27:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
>> 
>> 
>> #ifndef PNG_LOONGARCH_LSX_OPT
>> # if defined(__loongarch_sx)
>> # define PNG_LOONGARCH_LSX_OPT 1
>> # else
>> # define PNG_LOONGARCH_LSX_OPT 0
>> # endif
>> #endif
>> 
>> 
>> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.
>
> If PNG_LOONGARCH_LSX_OPT is set to 0 it disables all those extra fns
> https://github.com/openjdk/jdk/pull/18964/files
> 
> So LGTM.

Thanks for the review, @prrace. Is a second reviewer needed?

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

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

From haosun at openjdk.org  Wed Jul 30 06:04:55 2025
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 30 Jul 2025 06:04:55 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <4Mxnjj-pjt-LP4gFxL8HMA5805Nam6TbotfFsuC5Oj8=.65109ba8-508a-4674-9d32-82ec1b2fd80f@github.com>

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

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

Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.

### some details

JDK source: master
jtreg version: `8+2` version
JDK build: `fastdebug`
OS: `ubuntu 24.04`
two jtreg test cases

test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java
test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java

how to reproduce:

make test TEST="test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java"
make test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java


### the snippet of error log for case `TestSPISigned.java` on AArch64


STDERR:                                                                                                                                                                                                                                                      
java.nio.file.NoSuchFileException: /tmp/build-fastdebug/test-support/jtreg_test_jdk_java_security_SignedJar_spi_calendar_provider_TestSPISigned_java/classes/0/java/security/SignedJar/spi-calendar-provider/TestSPISigned.d/../provider/.                   
        at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)                                   
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
        at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
        at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:57)
        at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:161)
        at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
        at java.base/java.nio.file.Files.readAttributes(Files.java:1702)
        at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:216)                                                                                                                                                                     
        at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:268)   
        at java.base/java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:306)                                                                                                                                                                              
        at java.base/java.nio.file.FileTreeIterator.<init>(FileTreeIterator.java:69)                                          
        at java.base/java.nio.file.Files.find(Files.java:3649)                                                                
        at jdk.test.lib.util.JarUtils.findAllRegularFiles(JarUtils.java:425)                                                                                                                                                                                 
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:75)                                                         
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:106)                                                        
        at jdk.test.lib.util.JarUtils.createJarFile(JarUtils.java:115)                                                        
        at TestSPISigned.main(TestSPISigned.java:84)                                                                                                                                                                                                         
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)              
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)                                                         
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)                                                                                                                                                            at java.base/java.lang.Thread.run(Thread.java:1474)
                                                                                                                                                                                                                                                             
JavaTest Message: Test threw exception: java.nio.file.NoSuchFileException                                                     
JavaTest Message: shutting down test                 
                                                               
                                                                                                                                                                                                                                                             
TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.NoSuchFileException: /tmp/build-fastdebug/test-support/jtreg_test_jdk_java_security_SignedJar_spi_calendar_provider_TestSPISigned_java/classes/0/java/security/SignedJar/spi-cal
endar-provider/TestSPISigned.d/../provider/.
--------------------------------------------------
Test results: failed: 1

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

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

From hannesw at openjdk.org  Wed Jul 30 10:58:49 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 30 Jul 2025 10:58:49 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
Message-ID: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>

Please review a doc-only change to the API overview page to make other specs more discoverable. 

The new API overview page [can be viewed here](https://cr.openjdk.org/~hannesw/8294074/docs.00/api/index.html).

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

Commit messages:
 - JDK-8294074: Revert indentation changes
 - JDK-8294074: Make other specs more discoverable from the API docs

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

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

From alanb at openjdk.org  Wed Jul 30 11:11:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Jul 2025 11:11:56 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
In-Reply-To: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
Message-ID: <Vnn142_-M3RhsXfMqPdV0p6Dcz38GE0izDbAKjakDw8=.8147920a-e6ca-46a5-b888-428b8f9ff02a@github.com>

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

> Please review a doc-only change to the API overview page to make other specs more discoverable. 
> 
> The new API overview page [can be viewed here](https://cr.openjdk.org/~hannesw/8294074/docs.00/api/index.html).

make/Docs.gmk line 251:

> 249:     the Java virtual machine, and various tools, protocols, and file formats pertaining \
> 250:     to the Java platform.</p> \
> 251:     #

@hns Is this wording that is agreed elsewhere or are you open to suggestions on how this should be worded?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26547#discussion_r2242290678

From hannesw at openjdk.org  Wed Jul 30 12:09:55 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 30 Jul 2025 12:09:55 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
In-Reply-To: <Vnn142_-M3RhsXfMqPdV0p6Dcz38GE0izDbAKjakDw8=.8147920a-e6ca-46a5-b888-428b8f9ff02a@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
 <Vnn142_-M3RhsXfMqPdV0p6Dcz38GE0izDbAKjakDw8=.8147920a-e6ca-46a5-b888-428b8f9ff02a@github.com>
Message-ID: <nVTcBT8ivYRUccHVbW-CJn1Z_DkWNP6O7jREUrthyQ0=.096cf8a5-78d8-4da1-94b9-b14c24019838@github.com>

On Wed, 30 Jul 2025 11:09:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review a doc-only change to the API overview page to make other specs more discoverable. 
>> 
>> The new API overview page [can be viewed here](https://cr.openjdk.org/~hannesw/8294074/docs.00/api/index.html).
>
> make/Docs.gmk line 251:
> 
>> 249:     the Java virtual machine, and various tools, protocols, and file formats pertaining \
>> 250:     to the Java platform.</p> \
>> 251:     #
> 
> @hns Is this wording that is agreed elsewhere or are you open to suggestions on how this should be worded?

This wording is what we came up with in internal discussion, but certainly open to suggestions. I created this PR to make the process more transparent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26547#discussion_r2242420518

From prr at openjdk.org  Wed Jul 30 15:57:52 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 30 Jul 2025 15:57:52 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
 <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>
Message-ID: <tigrzjZUpuHr_yZyQ8T_Gky5uwV1hxqU2bVdU8yIHzA=.b6839a0d-de57-4516-ad01-ac670f90d4e3@github.com>

On Tue, 29 Jul 2025 17:27:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
>> 
>> 
>> #ifndef PNG_LOONGARCH_LSX_OPT
>> # if defined(__loongarch_sx)
>> # define PNG_LOONGARCH_LSX_OPT 1
>> # else
>> # define PNG_LOONGARCH_LSX_OPT 0
>> # endif
>> #endif
>> 
>> 
>> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.
>
> If PNG_LOONGARCH_LSX_OPT is set to 0 it disables all those extra fns
> https://github.com/openjdk/jdk/pull/18964/files
> 
> So LGTM.

> Thanks for the review, @prrace. Is a second reviewer needed?

I think wait another day to see if anyone from the build team wants to look.
@magicus ?

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

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

From jpai at openjdk.org  Wed Jul 30 16:29:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 30 Jul 2025 16:29:54 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>

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

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

Hello Hao,

> Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
> Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.

Thank you for bringing this up. I'm able to reproduce this issue with this newer version of jtreg. I'll take a look to see what's going on.

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

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

From aivanov at openjdk.org  Wed Jul 30 17:20:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 30 Jul 2025 17:20:54 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <AI062rZ6EnBO1C4T1FrvyEF-c7GMmAGIM1BqNl1AGeU=.5372aeb9-2ce9-4bda-af8f-fa47dcead4d2@github.com>

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

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

Looks good to me too.

As Phil suggested, you should wait for a day or two if anyone from the build team takes a look.

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

Marked as reviewed by aivanov (Reviewer).

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

From hannesw at openjdk.org  Wed Jul 30 17:31:39 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 30 Jul 2025 17:31:39 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
 [v2]
In-Reply-To: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
Message-ID: <txqR1xwh_eT8qrSPBt1VTec5JS4n3LHSV3s970t29jI=.957270cb-fff5-4e07-ba73-0cf709cd15a4@github.com>

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

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Update wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26547/files
  - new: https://git.openjdk.org/jdk/pull/26547/files/2c7236d8..7f038dea

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

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

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

From iris at openjdk.org  Wed Jul 30 18:56:54 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 30 Jul 2025 18:56:54 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
 [v2]
In-Reply-To: <nVTcBT8ivYRUccHVbW-CJn1Z_DkWNP6O7jREUrthyQ0=.096cf8a5-78d8-4da1-94b9-b14c24019838@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
 <Vnn142_-M3RhsXfMqPdV0p6Dcz38GE0izDbAKjakDw8=.8147920a-e6ca-46a5-b888-428b8f9ff02a@github.com>
 <nVTcBT8ivYRUccHVbW-CJn1Z_DkWNP6O7jREUrthyQ0=.096cf8a5-78d8-4da1-94b9-b14c24019838@github.com>
Message-ID: <eFoPisl6uw4csKJbO17Lq1lxswX886PWIO3deaOBNfk=.ddce2595-287d-4290-93f1-322e16814d85@github.com>

On Wed, 30 Jul 2025 12:06:49 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> make/Docs.gmk line 251:
>> 
>>> 249:     the Java virtual machine, and various tools, protocols, and file formats pertaining \
>>> 250:     to the Java platform.</p> \
>>> 251:     #
>> 
>> @hns Is this wording that is agreed elsewhere or are you open to suggestions on how this should be worded?
>
> This wording is what we came up with in internal discussion, but certainly open to suggestions. I created this PR to make the process more transparent.

Minimally, I would not refer to the narrative specs which are part of the platform as "Related documents" since that makes them sound weakly advisory/informational.  Perhaps something like "[Additional specifications][../specs/index.html] for the Java language...".

Also, if you're going to provide a link to the narrative specs, I'd also consider adding a reference to the external spec page (https://download.java.net/java/early_access/jdk25/docs/api/external-specs.html).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26547#discussion_r2243602685

From mr at openjdk.org  Wed Jul 30 19:57:56 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 30 Jul 2025 19:57:56 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
 [v2]
In-Reply-To: <txqR1xwh_eT8qrSPBt1VTec5JS4n3LHSV3s970t29jI=.957270cb-fff5-4e07-ba73-0cf709cd15a4@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
 <txqR1xwh_eT8qrSPBt1VTec5JS4n3LHSV3s970t29jI=.957270cb-fff5-4e07-ba73-0cf709cd15a4@github.com>
Message-ID: <stzNlTb548sJHWyz1JEV7ULjTUMD2go3FH9h7CbQ-0U=.ae8a97f2-d99f-4639-b285-df548707518a@github.com>

On Wed, 30 Jul 2025 17:31:39 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

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

Marked as reviewed by mr (Lead).

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

PR Review: https://git.openjdk.org/jdk/pull/26547#pullrequestreview-3073121679

From mr at openjdk.org  Wed Jul 30 19:57:56 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 30 Jul 2025 19:57:56 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
 [v2]
In-Reply-To: <eFoPisl6uw4csKJbO17Lq1lxswX886PWIO3deaOBNfk=.ddce2595-287d-4290-93f1-322e16814d85@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
 <Vnn142_-M3RhsXfMqPdV0p6Dcz38GE0izDbAKjakDw8=.8147920a-e6ca-46a5-b888-428b8f9ff02a@github.com>
 <nVTcBT8ivYRUccHVbW-CJn1Z_DkWNP6O7jREUrthyQ0=.096cf8a5-78d8-4da1-94b9-b14c24019838@github.com>
 <eFoPisl6uw4csKJbO17Lq1lxswX886PWIO3deaOBNfk=.ddce2595-287d-4290-93f1-322e16814d85@github.com>
Message-ID: <wPVOtY_QAvEqnMNjY4uFFVgl6DUA7n2oTtrpJk4iVqI=.09f48fa8-699d-4d6a-82b9-a7c8bf8d7116@github.com>

On Wed, 30 Jul 2025 18:53:40 GMT, Iris Clark <iris at openjdk.org> wrote:

>> This wording is what we came up with in internal discussion, but certainly open to suggestions. I created this PR to make the process more transparent.
>
> Minimally, I would not refer to the narrative specs which are part of the platform as "Related documents" since that makes them sound weakly advisory/informational.  Perhaps something like "[Additional specifications][../specs/index.html] for the Java language...".
> 
> Also, if you're going to provide a link to the narrative specs, I'd also consider adding a reference to the external spec page (https://download.java.net/java/early_access/jdk25/docs/api/external-specs.html).

The first word after ?related documents? is ?specify,? which doesn?t sound advisory to me.

I don?t think the external spec page is of sufficiently broad interest to highlight it here.

(To imply that our tool man pages are ?specifications? is a bit much, but making that distinction isn?t worth the trouble here.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26547#discussion_r2243721464

From hannesw at openjdk.org  Thu Jul 31 13:05:34 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 31 Jul 2025 13:05:34 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
 [v3]
In-Reply-To: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
Message-ID: <W_tthiYSzo03BgiUby-7BXqauJKs06F9B09ZxX0aLlc=.9d5ed074-ec95-4114-87f0-39cd0bf25e70@github.com>

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

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Minor changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26547/files
  - new: https://git.openjdk.org/jdk/pull/26547/files/7f038dea..e96c73da

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

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

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

From mr at openjdk.org  Thu Jul 31 17:36:55 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Thu, 31 Jul 2025 17:36:55 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
 [v3]
In-Reply-To: <W_tthiYSzo03BgiUby-7BXqauJKs06F9B09ZxX0aLlc=.9d5ed074-ec95-4114-87f0-39cd0bf25e70@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
 <W_tthiYSzo03BgiUby-7BXqauJKs06F9B09ZxX0aLlc=.9d5ed074-ec95-4114-87f0-39cd0bf25e70@github.com>
Message-ID: <cAb97WMashMahPakJ5ugvGORc9W_eb8s9DlzMP1v5DU=.c75f26ce-1a88-4948-9b1b-10a5dd7dbe0a@github.com>

On Thu, 31 Jul 2025 13:05:34 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

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

Marked as reviewed by mr (Lead).

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

PR Review: https://git.openjdk.org/jdk/pull/26547#pullrequestreview-3076347720

From jrose at openjdk.org  Thu Jul 31 18:37:54 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 31 Jul 2025 18:37:54 GMT
Subject: RFR: 8294074: Make other specs more discoverable from the API docs
 [v3]
In-Reply-To: <wPVOtY_QAvEqnMNjY4uFFVgl6DUA7n2oTtrpJk4iVqI=.09f48fa8-699d-4d6a-82b9-a7c8bf8d7116@github.com>
References: <R3JNY74TPLrHf8rvw0htFWRUaB2N_zvFObCfb1x7Mgk=.9348d300-08df-448a-8b21-ba37a765bb42@github.com>
 <Vnn142_-M3RhsXfMqPdV0p6Dcz38GE0izDbAKjakDw8=.8147920a-e6ca-46a5-b888-428b8f9ff02a@github.com>
 <nVTcBT8ivYRUccHVbW-CJn1Z_DkWNP6O7jREUrthyQ0=.096cf8a5-78d8-4da1-94b9-b14c24019838@github.com>
 <eFoPisl6uw4csKJbO17Lq1lxswX886PWIO3deaOBNfk=.ddce2595-287d-4290-93f1-322e16814d85@github.com>
 <wPVOtY_QAvEqnMNjY4uFFVgl6DUA7n2oTtrpJk4iVqI=.09f48fa8-699d-4d6a-82b9-a7c8bf8d7116@github.com>
Message-ID: <Kui3L_KpUi73I-d2E3D_z8e0mRqck1mh7dNpUcRf2g8=.ee9615ca-32d0-4976-aa2b-c47306db30cc@github.com>

On Wed, 30 Jul 2025 19:55:18 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Minimally, I would not refer to the narrative specs which are part of the platform as "Related documents" since that makes them sound weakly advisory/informational.  Perhaps something like "[Additional specifications][../specs/index.html] for the Java language...".
>> 
>> Also, if you're going to provide a link to the narrative specs, I'd also consider adding a reference to the external spec page (https://download.java.net/java/early_access/jdk25/docs/api/external-specs.html).
>
> The first word after ?related documents? is ?specify,? which doesn?t sound advisory to me.
> 
> I don?t think the external spec page is of sufficiently broad interest to highlight it here.
> 
> (To imply that our tool man pages are ?specifications? is a bit much, but making that distinction isn?t worth the trouble here.)

TIL about that external spec page. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26547#discussion_r2246108261