November 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: 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: 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: 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: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance
by Shaojin Wen 20 Feb '26

20 Feb '26

This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. Parsing scenarios show improvements from 12% to 95% ------------- Commit messages: - bug fix, form @liach - use EnumMap - add benchmark Changes: https://git.openjdk.org/jdk/pull/28471/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372460 Stats: 153 lines in 5 files changed: 149 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471 PR: https://git.openjdk.org/jdk/pull/28471

6 33

requesting review on JDK-8348828: Windows dll loading now resolves symlinks
by Benjamin Peterson 17 Feb '26

17 Feb '26

I've had a PR for the native library loading code up for a months that I'd appreciate any review on: https://github.com/openjdk/jdk/pull/24694 To summarize the issue and proposed fix: Before OpenJDK 24, System.loadLibrary on Windows passed symbolic links unresolved to the underlying LoadLibrary function. JDK-8003887 caused symbolic links to be resolved by Java before the system LoadLibrary function. Unfortunately, LoadLibrary is clever and may mangle the filename passed to it, which means passing a symlink may not have the same behavior as presenting the fully resolved path. I propose to fix this problem in the PR by disabling LoadLibrary's clever mangling behavior. Thank you for your time, Benjamin

2 5

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