- core-libs-dev - openjdk.org

RFR: 8375130: [BACKOUT] Scalability issue when submitting virtual threads with almost empty tasks
by Viktor Klang 06 Mar '26

06 Mar '26

Staging this as a Draft PR for now (FYI: @AlanBateman @DougLea) ------------- Commit messages: - Restoring setParallelism - Restoring VirtualThread changes - Adding acquire fence to FJP::push - Revert "8360046: Scalability issue when submitting virtual threads with almost empty tasks" Changes: https://git.openjdk.org/jdk/pull/30023/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30023&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375130 Stats: 467 lines in 2 files changed: 143 ins; 140 del; 184 mod Patch: https://git.openjdk.org/jdk/pull/30023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30023/head:pull/30023 PR: https://git.openjdk.org/jdk/pull/30023

2 4

RFR: 8379331: Remove modular transition support settings from TEST.ROOT files
by Christian Stein 06 Mar '26

06 Mar '26

Please review this removal of modular transition support settings from `TEST.ROOT` files. The `jtreg` tool dropped support for `useNewOptions` and `useNewPatchModule` around its 4.2 version: - "7901997: remove transition support for --patch-module" via https://github.com/openjdk/jtreg/commit/8362bffbc38b748c33f4920b8b18eace215… - "7901676: jtreg should drop support for old -Xpatch, -XaddReads, -XaddExports" via https://github.com/openjdk/jtreg/commit/1d52b5ab73e340dfa77cf7afa48674dcc68… ------------- Commit messages: - 8379331: Remove modular transition support settings from TEST.ROOT files Changes: https://git.openjdk.org/jdk/pull/30089/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30089&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379331 Stats: 25 lines in 5 files changed: 0 ins; 25 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/30089.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30089/head:pull/30089 PR: https://git.openjdk.org/jdk/pull/30089

3 2

RFR: 8379326: Use JUnit in lib-test/jdk tests, here MethodTemplateTest
by Christian Stein 06 Mar '26

06 Mar '26

Please review this change to use JUnit API in `MethodTemplateTest.java`. As only simple `assertTrue` and `assertFalse` are being called in test code, a swap of packages in `import` statements suffices. This pull request also disallows `testng` actions in `jtreg` under this test root to prevent future additions of TestNG-based tests. See the umbrella issue https://bugs.openjdk.org/browse/JDK-8307843 and its associated subtasks for details. ------------- Commit messages: - 8379326: Use JUnit in lib-test/jdk tests, here MethodTemplateTest Changes: https://git.openjdk.org/jdk/pull/30087/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30087&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379326 Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/30087.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30087/head:pull/30087 PR: https://git.openjdk.org/jdk/pull/30087

3 4

RFR: 8370691: Add new HalffloatVector type and enable intrinsification of float16 vector operations
by Jatin Bhateja 06 Mar '26

06 Mar '26

Add new HalffloatVector type and corresponding concrete vector classes in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. - Add necessary inline expander support. - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. - Use existing Float16 vector IR and backend support. - Extended the existing VectorAPI JTREG test suite for the newly added HalffloatVector operations. The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). The following are the performance numbers for some of the selected HalfflotVector benchmarking kernels compared to equivalent Float16OperationsBenchmark kernels. <img width="837" height="650" alt="{A2BA2D85-085A-489F-8DDD-0FCFB5986EA5}" src="https://github.com/user-attachments/assets/2f34138e-80f4-4870-9b5f-f64bf43c…" /> Initial RFP[1] was floated on the panama-dev mailing list. Kindly review the draft PR and share your feedback. Best Regards, Jatin [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html ------------- Commit messages: - Some cleanups - Fix some JTREG failures - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Revamped JTreg test generation and bug fixes - Cleanups - Removing redundant warmup constraint - Adding a HalffloatVectorBenchmark having benchmarking kernel parity with Float16OperationsBenchmark - Adding IR Framework test - Fix JTREG failures - Build failure fixes - ... and 1 more: https://git.openjdk.org/jdk/compare/e34a8318...c60d533c Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370691 Stats: 66541 lines in 134 files changed: 54467 ins; 460 del; 11614 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002

7 81

RFR: 8379345: jpackage: Fix issues in tests to improve their flexibility
by Alexey Semenyuk 06 Mar '26

06 Mar '26

A few jpackage tests have issues that don't show up when executed in the regular JDK test environment but fail in the local dev test environment: - MainTest#testFailedCommandOutput() unit test will fail if "jpackage.test.runtime-image" system property is set to skip jlink invocation. - A few test cases from SigningRuntimeImagePackageTest will fail if DMG bundling is disabled ("jpackage.test.disabledPackagers: system property is set to "dmg"). - Most of macOS signing tests are broken if executed on older macOS (Catalina). Even though this is an unsupported macOS version, it likely means these tests may fail on other macOS versions. It is difficult to determine which macOS version the problem first showed up in because these tests are skipped by default. This PR fixes the above issues identified in the JBS CR. Additionally, fix LicenseTest so it works when both DEB and RPM packaging are enabled; Remove `TKit.createRelativePathCopy()`; other changes are a follow-up. ------------- Commit messages: - LicenseTest: make it work when both DEB and RPM packagings are enabled; TKit: remove clunky createRelativePathCopy(); follow-up changes. - Tweaks to make signing tests work on Catalina - SigningRuntimeImagePackageTest: fix test failure when DMG bundling is disabled and the test uses PKG bundling to create signed predefined runtime bundle. - cli/MainTest: fix testFailedCommandOutput() to make it pass when running the test with run_tests.sh jpackage test runner with the specified external runtime Changes: https://git.openjdk.org/jdk/pull/30081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379345 Stats: 225 lines in 8 files changed: 114 ins; 68 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/30081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30081/head:pull/30081 PR: https://git.openjdk.org/jdk/pull/30081

2 4

RFR: 8379341: jpackage: consolidate modular app tests
by Alexey Semenyuk 06 Mar '26

06 Mar '26

Consolidate test cases from test/jdk/tools/jpackage/share/ModulePathTest.java test/jdk/tools/jpackage/share/ModulePathTest2.java test/jdk/tools/jpackage/share/ModulePathTest3.java test/jdk/tools/jpackage/share/NoMPathRuntimeTest.java tests into a new test/jdk/tools/jpackage/share/ModularAppTest.java. ------------- Commit messages: - ModularAppTest: consolidate modular app tests Changes: https://git.openjdk.org/jdk/pull/30082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379341 Stats: 815 lines in 5 files changed: 334 ins; 481 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/30082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30082/head:pull/30082 PR: https://git.openjdk.org/jdk/pull/30082

2 4

RFR: 8379348: jpackage will use wrong arch suffix for RPM bundle when running on Debian Linux
by Alexey Semenyuk 06 Mar '26

06 Mar '26

Fix jpackage to use the correct arch for DEB bundles when running on RPM-based Linux, and vice versa. The bug was in `jdk.jpackage.internal.LinuxBundlingEnvironment` class. Additionally: - Add missing single quote escape to `error.unexpected-default-package-property.advice` l10n string - Reworded `error.unexpected-package-property` l10n string - JPackageStringBundle: add `cannedFormattedStringAsPattern()`; throw when the number of format arguments doesn't match the number of format fields; add unit tests; ErrorTest, InstallDirTest: follow-up bugfixes - LinuxHelper: fix unexpected `java.lang.AssertionError: Failed: Check [libc] package is in the list of required packages [/bin/sh, /bin/sh, /bin/sh, rpmlib(CompressedFileNames) <= 3.0.4-1, rpmlib(PayloadFilesHavePrefix) <= 4.0-1] of [simplepackagetest] package` error when bundling RPM package on Ubuntu; Make `getDefaultPackageArch()` thread-safe ------------- Commit messages: - Update copyright year - JPackageCommand: add standard assert to check that jpackage's output doesn't contain the "wrong Linux package architecture" error - PackageProperty: bugfix & refactor; LinuxResources.properties: reword "error.unexpected-package-property"; Add missing single quote escape to the "error.unexpected-default-package-property.advice" message - LinuxBundlingEnvironment: fix jpackage correctly pick package arch on system where both RPM and DEB packaging is enabled. - InstallDirTest: bugfix revealed by tightening up JPackageStringBundle - JPackageStringBundle: add cannedFormattedStringAsPattern(); throw when the number of format arguments doesn't match the number of format fields; add unit tests; ErrorTest: follow-up bugfix - LinuxHelper: expose getReleaseSuffix(), make getDefaultPackageArch() thread-safe; JPackageCommand: add fullVersion() and improve version(); don't validate dependencies of alien (non-native) packages; Fix "java.lang.AssertionError: Failed: Check [libc] package is in the list of required packages [/bin/sh, /bin/sh, /bin/sh, rpmlib(CompressedFileNames) <= 3.0.4-1, rpmlib(PayloadFilesHavePrefix) <= 4.0-1] of [simplepackagetest] package" error when bundling RPM package on Ubuntu Changes: https://git.openjdk.org/jdk/pull/30085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30085&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379348 Stats: 567 lines in 14 files changed: 445 ins; 60 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/30085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30085/head:pull/30085 PR: https://git.openjdk.org/jdk/pull/30085

2 6

RFR: 8378559: Add setting of captured states like errno
by Paul Hübner 06 Mar '26

06 Mar '26

Hi all, This change enhances the Java foreign functions and memory API to allow users to inject thread-locals before a downcall. The lvalue `errno` is used for error handling in C. The C11 (draft) standard gives the following use-case example: > Thus, a program that uses errnofor error checking should set it to zero before a library function call, then inspect it before a subsequent library function call. Of course, a library function can save the value of errno on entry and then set it to zero, as long as the original value is restored if errno’s value is still zero just before the return. In the present day, it is possible to retrieve `errno` by using the API provided by `Linker.Option captureCallState`. This provides the Java-user a memory segment for thread-local data, that is populated by the JVM. The memory segment can be read using conventional FFM means, such as with a `VarHandle`. However, the contents of this segment is not used to populate the thread local data _before_ the downcall. As an example, in Java using the FFM API, an end user calling `strtol` and checking for `ERANGE` would do the following (in-line with the C standard footnote): set the captured call state buffer's `errno` to zero, perform a downcall, and then read the captured call state again to check if `errno` is still zero. While the memory segment sees `errno=0`, this is not actually written to the thread before execution. Thus, it is possible to observe stale or irrelevant error numbers. In this example, one could observe `ENOENT` after the `strtol` call, which is incorrect behaviour. This PR flushes the captured call state to the thread local variables before the downcall, ensuring that procedures in accordance to the C standard are possible. Since this was somewhat invasive, I ported it to non-Oracle platforms as well. One thing worth noting is that the setting and retrieving of thread local data is now coupled. Meaning, if a user wants to retrieve e.g. `errno` after a downcall, it is their responsibility to ensure that `errno` is appropriately set beforehand in order to make a meaningful comparison with predetermined error ranges. Testing: tiers 1-4 on Linux (x64, AArch64), macOS (x64, AArch64) and Windows (x64). I have built the JDK and run a [minimal but representative](https://gist.github.com/Arraying/41db1b093dfa5cc4bc49f12135… test case on Oracle Linux 10 (x64) with Zero (native), s390x, powerpc64le and riscv64 (all QEMU). I've smoke tested these platforms in good faith, but it would be good if porters with access to actual hardware could ensure that this change is sound. I would recommend running `:jdk_foreign` or `tier1`, at least. I will work on the CSR once the code changes and new specification have received sufficient review/feedback. ------------- Commit messages: - Copyright. - Copyright. - Improve test coverage. - New JavaDoc. - Port to RISC-V. - Port to PowerPC. - Port to s390. - Port to Zero. - Port to x86_64. - Fix comment order. - ... and 3 more: https://git.openjdk.org/jdk/compare/56060367...9e48fa35 Changes: https://git.openjdk.org/jdk/pull/30059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378559 Stats: 319 lines in 11 files changed: 223 ins; 7 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/30059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30059/head:pull/30059 PR: https://git.openjdk.org/jdk/pull/30059

5 9

RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns
by erifan 06 Mar '26

06 Mar '26

`VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. Current optimizations related to `VectorMaskCastNode` include: 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. This PR does the following optimizations: 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as the vector length remains the same, and this is guranteed in the api level. I conducted some simple research on different mask generation methods and mask operations, and obtained the following table, which includes some potential optimization opportunities that may use this `uncast_mask` function. <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta name=ProgId content=Excel.Sheet> <meta name=Generator content="Microsoft Excel 15"> <link id=Main-File rel=Main-File href="file:////Users/erfang/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip.htm"> <link rel=File-List href="file:////Users/erfang/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip_filelist.xml"> </head> <body link="#467886" vlink="#96607D"> mask_gen/op | toLong | anyTrue | allTrue | trueCount | firstTrue | lastTrue | and | or | xor | andNot | not | laneIsSet -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- compare | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | TBI | N/A maskAll | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI | TBI fromLong | TBI | TBI | N/A | TBI | TBI | TBI | N/A | N/A | N/A | N/A | TBI | TBI </body> </html> `TBI` indicated that there may be potential optimizations here that require further investigation. Benchmarks: On a Nvidia Grace machine with 128-bit SVE2: Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 59.23 0.21 148.12 0.07 2.50 microMaskLoadCastStoreDouble128 ops/us 2.43 0.00 38.31 0.01 15.73 microMaskLoadCastStoreFloat128 ops/us 6.19 0.00 75.67 0.11 12.22 microMaskLoadCastStoreInt128 ops/us 6.19 0.00 75.67 0.03 12.22 microMaskLoadCastStoreLong128 ops/us 2.43 0.00 38.32 0.01 15.74 microMaskLoadCastStoreShort64 ops/us 28.89 0.02 75.60 0.09 2.62 On a Nvidia Grace machine with 128-bit NEON: Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 75.75 0.19 149.74 0.08 1.98 microMaskLoadCastStoreDouble128 ops/us 8.71 0.03 38.71 0.05 4.44 microMaskLoadCastStoreFloat128 ops/us 24.05 0.03 76.49 0.05 3.18 microMaskLoadCastStoreInt128 ops/us 24.06 0.02 76.51 0.05 3.18 microMaskLoadCastStoreLong128 ops/us 8.72 0.01 38.71 0.02 4.44 microMaskLoadCastStoreShort64 ops/us 24.64 0.01 76.43 0.06 3.10 On an AMD EPYC 9124 16-Core Processor with AVX3: Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 82.13 0.31 115.14 0.08 1.40 microMaskLoadCastStoreDouble128 ops/us 0.32 0.00 0.32 0.00 1.01 microMaskLoadCastStoreFloat128 ops/us 42.18 0.05 57.56 0.07 1.36 microMaskLoadCastStoreInt128 ops/us 42.19 0.01 57.53 0.08 1.36 microMaskLoadCastStoreLong128 ops/us 0.30 0.01 0.32 0.00 1.05 microMaskLoadCastStoreShort64 ops/us 42.18 0.05 57.59 0.01 1.37 On an AMD EPYC 9124 16-Core Processor with AVX2: Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 73.53 0.20 114.98 0.03 1.56 microMaskLoadCastStoreDouble128 ops/us 0.29 0.01 0.30 0.00 1.00 microMaskLoadCastStoreFloat128 ops/us 30.78 0.14 57.50 0.01 1.87 microMaskLoadCastStoreInt128 ops/us 30.65 0.26 57.50 0.01 1.88 microMaskLoadCastStoreLong128 ops/us 0.30 0.00 0.30 0.00 0.99 microMaskLoadCastStoreShort64 ops/us 24.92 0.00 57.49 0.01 2.31 On an AMD EPYC 9124 16-Core Processor with AVX1: Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 79.68 0.01 248.49 0.91 3.12 microMaskLoadCastStoreDouble128 ops/us 0.28 0.00 0.28 0.00 1.00 microMaskLoadCastStoreFloat128 ops/us 31.11 0.04 95.48 2.27 3.07 microMaskLoadCastStoreInt128 ops/us 31.10 0.03 99.94 1.87 3.21 microMaskLoadCastStoreLong128 ops/us 0.28 0.00 0.28 0.00 0.99 microMaskLoadCastStoreShort64 ops/us 31.11 0.02 94.97 2.30 3.05 This PR was tested on 128-bit, 256-bit, and 512-bit (QEMU) aarch64 environments, and two 512-bit x64 machines. With various configurations, including sve2, sve1, neon, avx3, avx2, avx1, sse4 and sse3, all tests passed. ------------- Commit messages: - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns Changes: https://git.openjdk.org/jdk/pull/28313/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370863 Stats: 582 lines in 7 files changed: 498 ins; 0 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/28313.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28313/head:pull/28313 PR: https://git.openjdk.org/jdk/pull/28313

6 67

RFR: 8379334: jpackage: fix bug in DottedVersion.greedy() function
by Alexey Semenyuk 06 Mar '26

06 Mar '26

For the "1.2.3+ea" string, the `DottedVersion.greedy()` function returns an instance whose `getUnprocessedSuffix()` returns ".3+ea". The expected value is "+ea". Fixed the implementation and added missing test cases. Additionally: - Added `trim()` and `pad()` methods. - Replaced `DottedVersion.DigitsSupplier.throwException(`) with `DottedVersion.DigitsSupplier.createException()` to increase coverage. Somehow, `throw ds.createException()` is marked as covered, and `ds.throwException()` is marked as uncovered. Probably because in the latter case, the call never returns. ------------- Commit messages: - DottedVersion: add trim() and pad(). - DottedVersion: bugfix and better coverage Changes: https://git.openjdk.org/jdk/pull/30080/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30080&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379334 Stats: 178 lines in 2 files changed: 156 ins; 6 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/30080.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30080/head:pull/30080 PR: https://git.openjdk.org/jdk/pull/30080

2 5