September 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: 8367603: Optimize exact division in BigDecimal
by fabioromano1 05 Mar '26

05 Mar '26

A formula to lower the overestimate for the precision of an exact quotient, without introduce too expensive operations of division on numerator and denominator. [Here is a proof for the formula.](https://github.com/user-attachments/files/22314648/frazioni_decim… ------------- Commit messages: - Add time tests - Added link to proof - Optimize exact division Changes: https://git.openjdk.org/jdk/pull/27271/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367603 Stats: 199 lines in 2 files changed: 175 ins; 16 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27271/head:pull/27271 PR: https://git.openjdk.org/jdk/pull/27271

3 54

RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort)
by Vladimir Yaroslavskiy 04 Mar '26

04 Mar '26

The goal of the PR is to improve both, sequential and parallel, sorting of primitives. **The main achievements** - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n) - improved mixed insertion sort (makes whole sorting faster) - improved merging sort for almost sorted data - optimized parallel sorting - improved step for pivot candidates and pivot partitioning - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError - minor javadoc and comment changes - extended existing tests - added tests for radix sort, heap sort, insertion sort - added benchmarking JMH tests - improved test coverage **The summary of benchmarking:** **Sequential sorting (Arrays.sort)** byte: up to 50% faster char: 4-7 times faster short: 2-6 times faster int: 1.2-5 times faster long: 1.2-5 times faster float: 1.2-5 times faster double: 1.2-4 times faster **Parallel sorting (Arrays.parallelSort)** int: 1.2-9 times faster long: 1.2-9 times faster float: 1.2-4 times faster double: 1.2-4 times faster **AVX512 support** Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results. I'm going on previous PRs https://github.com/openjdk/jdk/pull/3938 and https://github.com/openjdk/jdk/pull/13568 ------------- Commit messages: - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) Changes: https://git.openjdk.org/jdk/pull/27411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27411&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8266431 Stats: 6295 lines in 4 files changed: 2359 ins; 1907 del; 2029 mod Patch: https://git.openjdk.org/jdk/pull/27411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27411/head:pull/27411 PR: https://git.openjdk.org/jdk/pull/27411

8 41

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: 8344159: Add lint warnings for unnecessary warning suppression
by Archie Cobbs 10 Feb '26

10 Feb '26

This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. Summary of code changes: * Add new warning and associated lint category `"suppression"` * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ¹ * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break ¹ The suppression of a lint category is "validated" as soon as it suppresses some warning in that category ------------- Commit messages: - Add clarifying comment. - Merge branch 'master' into JDK-8344159 - Change inner class name to avoid shadowing superclass name. - Add a couple of code clarification comments. - Refactor test to avoid requiring changes to TestRunner. - Remove unnecessary -Xlint:-suppression flags. - Minor cleanups. - Add OPTIONS, PATH, and SUPPRESSION to the regression test. - Minor regression test cleanups. - Minor comment tweaks. - ... and 120 more: https://git.openjdk.org/jdk/compare/11cdafb8...e3283ba9 Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344159 Stats: 1661 lines in 33 files changed: 1485 ins; 51 del; 125 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167

6 27

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: 8366444: Add support for add/mul reduction operations for Float16
by Bhavana Kilambi 09 Feb '26

09 Feb '26

This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - **For AddReduction :** On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. **For MulReduction :** Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. Ratio > 1 indicates the performance with this patch is better than the master branch. **N1 (UseSVE = 0, max vector length = 16B):** Benchmark vectorDim Mode Cnt 8B 16B ReductionAddFP16 256 thrpt 9 1.41 1.40 ReductionAddFP16 512 thrpt 9 1.41 1.41 ReductionAddFP16 1024 thrpt 9 1.43 1.40 ReductionAddFP16 2048 thrpt 9 1.43 1.40 ReductionMulFP16 256 thrpt 9 1.22 1.22 ReductionMulFP16 512 thrpt 9 1.21 1.23 ReductionMulFP16 1024 thrpt 9 1.21 1.22 ReductionMulFP16 2048 thrpt 9 1.20 1.22 On N1, the scalarized sequence of `fadd/fmul` are generated for both `MaxVectorSize` of 8B and 16B for add reduction and mul reduction respectively. **V1 (UseSVE = 1, max vector length = 32B):** Benchmark vectorDim Mode Cnt 8B 16B 32B ReductionAddFP16 256 thrpt 9 1.11 1.75 2.02 ReductionAddFP16 512 thrpt 9 1.02 1.64 1.93 ReductionAddFP16 1024 thrpt 9 1.02 1.59 1.85 ReductionAddFP16 2048 thrpt 9 1.02 1.56 1.80 ReductionMulFP16 256 thrpt 9 1.12 0.99 1.09 ReductionMulFP16 512 thrpt 9 1.04 1.01 1.04 ReductionMulFP16 1024 thrpt 9 1.02 1.02 1.00 ReductionMulFP16 2048 thrpt 9 1.01 1.01 1.00 On V1, for MaxVectorSize = 8: scalarized `fadd/fmul` sequence will be generated for `AddReductionVHF/MulReductionVHF` as UseSVE defaults to 0 [2]. For MaxVectorSize = 16: scalarized `fmul` sequence is generated for `MulReductionVHF` and `fadda` is generated for `AddReductionVHF` which fetches signficant gains. For MaxVectorSize = 32: Autovectorization of `MulReductionVHF` is disabled for MaxVectorSize > 16B so the autovectorizer checks for maximal implemented size[1] which is 16B and generates scalarized `fmul` sequence for 16B in this case. For `AddReductionVHF`, it generates the `fadda` instruction. **V2 (UseSVE = 2, max vector length = 16B)** Benchmark vectorDim Mode Cnt 8B 16B ReductionAddFP16 256 thrpt 9 1.16 1.70 ReductionAddFP16 512 thrpt 9 1.02 1.61 ReductionAddFP16 1024 thrpt 9 1.01 1.53 ReductionAddFP16 2048 thrpt 9 1.00 1.49 ReductionMulFP16 256 thrpt 9 1.18 0.99 ReductionMulFP16 512 thrpt 9 1.04 1.01 ReductionMulFP16 1024 thrpt 9 1.02 1.02 ReductionMulFP16 2048 thrpt 9 1.01 1.01 On V2, for MaxVectorSize = 8: scalarized `fadd/fmul` sequence will be generated as UseSVE defaults to 0 [2]. For MaxVectorSize = 16: `fadda` instruction is generated for `AddReductionVHF` which results in significant gains in performance. For `MulReductionVHF`, the scalarized `fmul` sequence will be generated. **Testing:** hotspot_all, jdk(tiers1-3) and langtools(tier1) all pass on N1/V1/V2. [1] https://github.com/openjdk/jdk/blob/a272696813f2e5e896ac9de9985246aaeb9d476… [2] https://github.com/openjdk/jdk/blob/a272696813f2e5e896ac9de9985246aaeb9d476… ------------- Commit messages: - 8366444: Add support for add/mul reduction operations for Float16 Changes: https://git.openjdk.org/jdk/pull/27526/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366444 Stats: 500 lines in 12 files changed: 421 ins; 2 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/27526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27526/head:pull/27526 PR: https://git.openjdk.org/jdk/pull/27526

7 59