August 2025 - core-libs-dev

RFR: 8364007: Add overload without arguments to codePointCount in String etc.
by Tatsunori Uchino 08 Mar '26

08 Mar '26

Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { throw new Exception("exceeding length"); } Is a CSR required to this change? ------------- Commit messages: - Remove trailing spaces - 8364007: Add overload without arguments to codePointCount in String etc. Changes: https://git.openjdk.org/jdk/pull/26461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364007 Stats: 112 lines in 13 files changed: 95 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461

7 91

RFR: 8352171: Arrays.hashCode for sub-range of byte array API addition
by Zihao Lin 06 Mar '26

06 Mar '26

Add the java.util.Arrays.hashCode(byte[], int start, int end). Hi team, I am new here, please give me some guidance. Thank you. ------------- Commit messages: - 8352171: Arrays.hashCode for sub-range of byte array API addition Changes: https://git.openjdk.org/jdk/pull/24128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352171 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24128/head:pull/24128 PR: https://git.openjdk.org/jdk/pull/24128

6 17

RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction
by Jatin Bhateja 27 Feb '26

27 Feb '26

Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). Vector API jtreg tests pass at AVX level 2, remaining validation in progress. Performance numbers: System : 13th Gen Intel(R) Core(TM) i3-1315U Baseline: Benchmark (size) Mode Cnt Score Error Units VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 thrpt 2 9756.573 ops/ms With opt: Benchmark (size) Mode Cnt Score Error Units VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 34122.435 ops/ms VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 33281.868 ops/ms VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9345.154 ops/ms VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 8283.247 ops/ms VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 8510.695 ops/ms VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 5626.367 ops/ms VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 960.958 ops/ms VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 4155.801 ops/ms VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1465.953 ops/ms VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 32748.061 ops/ms VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 33674.408 ops/ms VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 thrpt 2 9346.148 ops/ms Please share your feedback. Best Regards, Jatin ------------- Commit messages: - Fixes for failing regressions - Optimizing AVX2 backend and some re-factoring - new benchmark - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8303762 - 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction Changes: https://git.openjdk.org/jdk/pull/24104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303762 Stats: 747 lines in 32 files changed: 664 ins; 0 del; 83 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104

7 67

RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface
by Tagir F. Valeev 13 Feb '26

13 Feb '26

Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html The specification is mostly composed of Math.min/max and Collections.min/max specifications. The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them. I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here. ------------- Commit messages: - Fix linebreaks - JDK-8356995 Provide default methods min(T, T) and max(T, T) in Comparator interface Changes: https://git.openjdk.org/jdk/pull/25297/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25297&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356995 Stats: 112 lines in 2 files changed: 110 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25297/head:pull/25297 PR: https://git.openjdk.org/jdk/pull/25297

10 37

RFR: 8348828: Windows dll loading now resolves symlinks
by Benjamin Peterson 11 Feb '26

11 Feb '26

Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was called on the target library file before it was passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. Fix this problem by using `File.getAbsolutePath()` instead of `File.getCanonicalPath()` in `NativeLibraries.java`. ------------- Commit messages: - 8348828: Windows dll loading now resolves symlinks Changes: https://git.openjdk.org/jdk/pull/24694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348828 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694

6 49

RFR: 8347009: Speed up parseInt and parseLong
by Shaojin Wen 09 Feb '26

09 Feb '26

This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. ------------- Commit messages: - optimize parseInt & parseLong - optimize parseInt & parseLong - reuse isDigit - optimize parseInt - optimize parseLong - add benchmark Changes: https://git.openjdk.org/jdk/pull/22919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347009 Stats: 141 lines in 4 files changed: 65 ins; 16 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919

7 67

RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava
by Brian Burkhalter 04 Feb '26

04 Feb '26

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. ------------- Commit messages: - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337143 Stats: 1265 lines in 75 files changed: 631 ins; 523 del; 111 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

6 102

RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
by Chen Liang 30 Jan '26

30 Jan '26

Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well. To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks. ------------- Commit messages: - Remove redundant try-catch in getEnclosingMethod/Constructor - Merge branch 'test/signature-error' into feature/new-generic-info - Fix everything - Fixxes - Stage - Stage new tests - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info - ... and 5 more: https://git.openjdk.org/jdk/compare/8aeada10...4110c13f Changes: https://git.openjdk.org/jdk/pull/19281/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19281&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333377 Stats: 4605 lines in 66 files changed: 1027 ins; 3483 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/19281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19281/head:pull/19281 PR: https://git.openjdk.org/jdk/pull/19281

4 20

RFR: 8359424: Eliminate table lookup in Integer/Long toHexString
by Shaojin Wen 24 Jan '26

24 Jan '26

In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 - use right shift - use right shift - fix benchmark - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 - reverseBytes - reverseBytes - public hex8 - ... and 9 more: https://git.openjdk.org/jdk/compare/e18277b4...6f491ced Changes: https://git.openjdk.org/jdk/pull/22942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359424 Stats: 262 lines in 6 files changed: 178 ins; 77 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/22942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22942/head:pull/22942 PR: https://git.openjdk.org/jdk/pull/22942

6 23

RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
by Severin Gehwolf 23 Jan '26

23 Jan '26

Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). This patch addresses this issue by: 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been proposed in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. Thoughts? Testing: - [ ] GHA - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems - [x] Some manual testing using systemd slices ------------- Depends on: https://git.openjdk.org/jdk/pull/17198 Commit messages: - 8336881: [Linux] Support for hierarchical limits for Metrics Changes: https://git.openjdk.org/jdk/pull/20280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336881 Stats: 1511 lines in 24 files changed: 1260 ins; 152 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280

3 32