- core-libs-dev - openjdk.org

RFR: 8375045: Incorrect Interpretation of POSIX TZ Environment Variable on AIX.
by Sruthy Jayan 05 Mar '26

05 Mar '26

Bug Reference : https://bugs.openjdk.org/browse/JDK-8375045 On AIX, the POSIX TZ environment variable is not interpreted as expected when it includes DST rules. Example: `TZ=CET-1CEST,M3.5.0,M10.5.0` The fix includes : The TZ environment variable is processed by first matching the full value against tzmappings, then retrying with the value truncated at the first comma if no match is found, and finally defaulting to GMT if no mapping exists. This fixes the regression caused by https://bugs.openjdk.org/browse/JDK-8292899 Signed-off-by: Sruthy Jayan <srutjay1(a)in.ibm.com> ------------- Commit messages: - Fix to handle Incorrect Interpretation of POSIX TZ Environment Variable on AIX Changes: https://git.openjdk.org/jdk/pull/29183/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29183&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375045 Stats: 61 lines in 1 file changed: 39 ins; 18 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29183/head:pull/29183 PR: https://git.openjdk.org/jdk/pull/29183

3 8

RFR: 8378796: java.lang.runtime bootstrap methods missing lookup validation
by Chen Liang 05 Mar '26

05 Mar '26

The bootstrap methods in java.lang.runtime do not have explicit requirements for the lookup; they largely ignored it until they suddenly start using the lookups. Currently, the unprivileged lookup behavior is as follows: 1. `ObjectMethods.bootstrap` for `equals` and `hashCode` may fail with `IllegalAccessException` if the lookup is used to generate hidden classes; it may be ignored if no hidden class is needed. 2. `ObjectMethods.bootstrap` for `toString` fails with a `RuntimeException` caused by a `StringConcatException`. 3. `SwitchBootstraps` methods fail with `IllegalArgumentException` caused by `IllegalAccessException`. In contrast, `LambdaMetafactory` and `StringConcatFactory` throw their own types of exceptions. In this patch, I decided to make all these java.lang.runtime BSMs throw `IllegalArgumentException` without a cause for any unprivileged lookup that cannot support bytecode generation. Future BSMs should also reject unprivileged lookup eagerly to allow implementations to have bytecode generation freedom. The `IllegalArgumentException` is consistent with other consistency checks done by these BSMs. ------------- Commit messages: - 8378796: java.lang.runtime bootstrap methods missing lookup validation Changes: https://git.openjdk.org/jdk/pull/30067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378796 Stats: 89 lines in 5 files changed: 42 ins; 19 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/30067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30067/head:pull/30067 PR: https://git.openjdk.org/jdk/pull/30067

2 9

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: 8379337: Deprecate Modifier.toString
by Chen Liang 05 Mar '26

05 Mar '26

> This method tries to describe the source modifiers from an access flags > value. Since the introduction of this API, new source modifiers are > often represented by `class` file constructs other than access > flags, and access flags values in different `class` file > structures have different interpretations. As a result, the source > modifiers reported by this API may be incomplete or incorrect. > > The source modifiers of a declaration should be reconstructed manually, > by examining its reflective object. In addition, the reflective object > methods that provide user-friendly text representations, such as > `Class#toGenericString()`, render the source modifiers. > > The access flags of a declaration, with the correct interpretation, can > be obtained from the `accessFlags()` methods on the reflective > objects, such as `Class#accessFlags()`. > > To print an access flags value for debug output, consider using the > format ``%04x` instead of this method; this method omits all class > file access flags without a corresponding source modifier. ------------- Commit messages: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/deprecate-modifier-tostring - Deprecate Modifier.toString Changes: https://git.openjdk.org/jdk/pull/30093/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30093&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379337 Stats: 262 lines in 15 files changed: 172 ins; 41 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/30093.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30093/head:pull/30093 PR: https://git.openjdk.org/jdk/pull/30093

1 0

RFR: 8373344: Add support for FP16 min/max reduction operations
by Yi Wu 05 Mar '26

05 Mar '26

This patch adds mid-end support for vectorized min/max reduction operations for half floats. It also includes backend AArch64 support for these operations. Both floating point min/max reductions don’t require strict order, because they are associative. It will generate NEON fminv/fmaxv reduction instructions when max vector length is 8B or 16B. On SVE supporting machines with vector lengths > 16B, it will generate the SVE fminv/fmaxv instructions. The patch also adds support for partial min/max reductions on SVE machines using fminv/fmaxv. Ratio of throughput(ops/ms) > 1 indicates the performance with this patch is better than the mainline. Neoverse N1 (UseSVE = 0, max vector length = 16B): Benchmark vectorDim Mode Cnt 8B 16B ReductionMaxFP16 256 thrpt 9 3.69 6.44 ReductionMaxFP16 512 thrpt 9 3.71 7.62 ReductionMaxFP16 1024 thrpt 9 4.16 8.64 ReductionMaxFP16 2048 thrpt 9 4.44 9.12 ReductionMinFP16 256 thrpt 9 3.69 6.43 ReductionMinFP16 512 thrpt 9 3.70 7.62 ReductionMinFP16 1024 thrpt 9 4.16 8.64 ReductionMinFP16 2048 thrpt 9 4.44 9.10 Neoverse V1 (UseSVE = 1, max vector length = 32B): Benchmark vectorDim Mode Cnt 8B 16B 32B ReductionMaxFP16 256 thrpt 9 3.96 8.62 8.02 ReductionMaxFP16 512 thrpt 9 3.54 9.25 11.71 ReductionMaxFP16 1024 thrpt 9 3.77 8.71 14.07 ReductionMaxFP16 2048 thrpt 9 3.88 8.44 14.69 ReductionMinFP16 256 thrpt 9 3.96 8.61 8.03 ReductionMinFP16 512 thrpt 9 3.54 9.28 11.69 ReductionMinFP16 1024 thrpt 9 3.76 8.70 14.12 ReductionMinFP16 2048 thrpt 9 3.87 8.45 14.70 Neoverse V2 (UseSVE = 2, max vector length = 16B): Benchmark vectorDim Mode Cnt 8B 16B ReductionMaxFP16 256 thrpt 9 4.78 10.00 ReductionMaxFP16 512 thrpt 9 3.74 11.33 ReductionMaxFP16 1024 thrpt 9 3.86 9.59 ReductionMaxFP16 2048 thrpt 9 3.94 8.71 ReductionMinFP16 256 thrpt 9 4.78 10.00 ReductionMinFP16 512 thrpt 9 3.74 11.29 ReductionMinFP16 1024 thrpt 9 3.86 9.58 ReductionMinFP16 2048 thrpt 9 3.94 8.71 Testing: hotspot_all, jdk (tier1-3) and langtools (tier1) all pass on Neoverse N1/V1/V2. ------------- Commit messages: - 8373344: Add support for FP16 min/max reduction operations Changes: https://git.openjdk.org/jdk/pull/28828/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373344 Stats: 968 lines in 13 files changed: 296 ins; 22 del; 650 mod Patch: https://git.openjdk.org/jdk/pull/28828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28828/head:pull/28828 PR: https://git.openjdk.org/jdk/pull/28828

4 7

RFR: 8341608: SignaturesImpl: tolerate empty identifier after '.' in class type signatures
by Hyeonsoo Lee 05 Mar '26

05 Mar '26

## Summary Follow-up to [JDK-8341608](https://bugs.openjdk.org/browse/JDK-8341608), which addressed `ClassFileError` propagation in jdeps but did not fix the underlying signature parsing. `SignaturesImpl.classTypeSig()` throws `IllegalArgumentException` when parsing a class type signature that contains an empty identifier after the inner class separator `.`. ## Problem The Scala compiler emits class type signatures such as: Lcoursierapi/shaded/scala/collection/immutable/TreeMap$TreeMapBuilder<TK;TV;>.; Here the `.` after the type arguments is followed directly by `;` with no inner class name. While this violates JVMS §4.7.9.1 (which requires an identifier after `.`), such signatures exist widely in published Scala artifacts on Maven Central and cannot be recompiled. Running `jdeps` against JARs containing these signatures crashes with: Exception in thread "main" com.sun.tools.jdeps.Dependencies$ClassFileError Caused by: java.lang.IllegalArgumentException: Unexpected character ; at position 78, expected an identifier ## Fix In `classTypeSig()`, the identifier after `.` is now optional when an outer type is already present. On the first iteration (no outer type), an identifier is still strictly required. ## Test Added `LOuter<TK;TV;>.;` to `goodTypeSignatures` in `SignaturesTest`. ------------- Commit messages: - SignaturesImpl: tolerate empty identifier after '.' in class type signatures Changes: https://git.openjdk.org/jdk/pull/30041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341608 Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/30041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30041/head:pull/30041 PR: https://git.openjdk.org/jdk/pull/30041

2 7

RFR: 8358521: Optimize vector operations by reassociating broadcasted inputs
by Jatin Bhateja 05 Mar '26

05 Mar '26

Hi all, This patch optimizes SIMD kernels making heavy use of broadcasted inputs through following reassociating ideal transformations. VectorOperation (VectorBroadcast INP1, VectorBroadcast INP2) => VectorBroadcast (ScalarOpration INP1, INP2) VectorOperation (VectorBroadcast INP1) (VectorOperation (VectorBroadcast INP2) INP3) => VectorOperation INP3 (VectorOperation (VectorBroadcast INP1) (VectorOperation INP2)) The idea is to push broadcasts across the vector operation and replace the vector with an equivalent, cheaper scalar variant. Currently, patch handles most common vector operations. Following are the performance number of benchmark included with this patch on latest generation x86 targets:- **AMD Turin (2.1GHz)** <img width="1122" height="355" alt="image" src="https://github.com/user-attachments/assets/3f5087bf-0e14-4c56-b0c2-3d23253b…" /> **Intel Granite Rapids (2.1GHz)** <img width="1105" height="325" alt="image" src="https://github.com/user-attachments/assets/c8481f86-4db2-4c4e-bd65-51542c59…" /> Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - Adding JTREG testcase - Clanups - Adding a benchmark - Adding VectorNode::Ideal on Idealazation exit - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8358521 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8358521 - Updates - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8358521 - Skip optimizing predicated vector operations - 8358521: Optimize vector operations with broadcasted inputs Changes: https://git.openjdk.org/jdk/pull/25617/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25617&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358521 Stats: 911 lines in 6 files changed: 887 ins; 15 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25617.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25617/head:pull/25617 PR: https://git.openjdk.org/jdk/pull/25617

4 19

RFR: 8372353: API to compute the byte length of a String encoded in a given Charset
by Liam Miller-Cushon 05 Mar '26

05 Mar '26

This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. --- Benchmark (encoding) (stringLength) Mode Cnt Score Error Units StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ± 16960032.852 ops/s StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ± 4532029.201 ops/s StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ± 2413274.766 ops/s StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ± 12818.317 ops/s StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ± 3962947.391 ops/s StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ± 1267331.434 ops/s StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ± 41718.545 ops/s StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ± 10296.120 ops/s StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ± 8326589.199 ops/s StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ± 4808526.773 ops/s StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ± 70636.784 ops/s StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ± 1887.112 ops/s StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ± 76938927.141 ops/s StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ± 15167234.884 ops/s StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ± 794027.897 ops/s StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ± 1916.468 ops/s StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ± 17013983.056 ops/s StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ± 5842185.781 ops/s StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ± 3839233.582 ops/s StringLoopJmhBenchmark.getBytesLength LATIN1 100000 thrpt 5 1136360.285 ± 426475.121 ops/s StringLoopJmhBenchmark.getBytesLength UTF16 10 thrpt 5 329508584.830 ± 6277534.933 ops/s StringLoopJmhBenchmark.getBytesLength UTF16 100 thrpt 5 86396600.366 ± 4287569.267 ops/s StringLoopJmhBenchmark.getBytesLength UTF16 1000 thrpt 5 10037994.564 ± 779239.446 ops/s StringLoopJmhBenchmark.getBytesLength UTF16 100000 thrpt 5 99218.929 ± 2854.843 ops/s StringLoopJmhBenchmark.utf8LenByLoop ASCII 10 thrpt 5 409066999.717 ± 25444799.130 ops/s StringLoopJmhBenchmark.utf8LenByLoop ASCII 100 thrpt 5 72126088.461 ± 42992009.452 ops/s StringLoopJmhBenchmark.utf8LenByLoop ASCII 1000 thrpt 5 8300806.448 ± 533912.423 ops/s StringLoopJmhBenchmark.utf8LenByLoop ASCII 100000 thrpt 5 87356.021 ± 7863.743 ops/s StringLoopJmhBenchmark.utf8LenByLoop LATIN1 10 thrpt 5 356802960.574 ± 24814016.238 ops/s StringLoopJmhBenchmark.utf8LenByLoop LATIN1 100 thrpt 5 85043539.617 ± 30538310.706 ops/s StringLoopJmhBenchmark.utf8LenByLoop LATIN1 1000 thrpt 5 9952675.100 ± 2922230.486 ops/s StringLoopJmhBenchmark.utf8LenByLoop LATIN1 100000 thrpt 5 79410.881 ± 50777.786 ops/s StringLoopJmhBenchmark.utf8LenByLoop UTF16 10 thrpt 5 304196311.102 ± 20381571.060 ops/s StringLoopJmhBenchmark.utf8LenByLoop UTF16 100 thrpt 5 84223829.681 ± 10787815.139 ops/s StringLoopJmhBenchmark.utf8LenByLoop UTF16 1000 thrpt 5 11046224.275 ± 1200731.406 ops/s StringLoopJmhBenchmark.utf8LenByLoop UTF16 100000 thrpt 5 112590.802 ± 3741.019 ops/s ------------- Commit messages: - Whitespace - Apply suggestions from code review - 8372353: API to compute the byte length of a String encoded in a given Charset Changes: https://git.openjdk.org/jdk/pull/28454/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372353 Stats: 213 lines in 4 files changed: 213 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454

8 107

RFR: 8378737: AArch64: Fix SVE match rule issues for VectorMask.andNot()
by Xiaohong Gong 05 Mar '26

05 Mar '26

Duplicate `ptrue`(`MaskAll`) instructions are generated with different predicate registers on SVE when multiple `VectorMask.not()` operations exist. This increases the predicate register pressure and reduces performance, especially after loop is unrolled. Root cause: the matcher clones `MaskAll` for each `not` pattern (i.e. `(XorVMask (MaskAll m1))`), but SVE has no match rule for that alone. And the cloned `MaskAll` nodes are not shared with each other. Since SVE has rules for the `andNot` pattern: match(Set pd (AndVMask pn (XorVMask pm (MaskAll m1)))); `MaskAll` node should be cloned only when it is part of the `andNot` pattern instead. A second issue: `AndVMask`, `OrVMask`, and `XorVMask` are not in the matcher's commutative vector op list, so their operands are never swapped. As a result, the `andNot` rule does not match when the `XorVMask` operands appear in the opposite order (e.g. `(XorVMask (MaskAll m1) pm)`). This patch fixes both issues by 1) limiting when `MaskAll` is cloned and 2) adding the three binary mask bitwise IRs to the commutative op list. Following is the performance result of the new added JMH tested on V1 and Grace(V2) machines respecitively: V1 (SVE machine with 256-bit vector length): Benchmark Mode Threads Samples Unit size Before After Gain MaskLogicOperationsBenchmark.byteMaskAndNot thrpt 1 30 ops/ms 256 54465.231 74374.960 1.365 MaskLogicOperationsBenchmark.byteMaskAndNot thrpt 1 30 ops/ms 512 29156.881 39601.358 1.358 MaskLogicOperationsBenchmark.byteMaskAndNot thrpt 1 30 ops/ms 1024 15169.894 20272.379 1.336 MaskLogicOperationsBenchmark.intMaskAndNot thrpt 1 30 ops/ms 256 15408.510 19808.722 1.285 MaskLogicOperationsBenchmark.intMaskAndNot thrpt 1 30 ops/ms 512 7906.952 10297.837 1.302 MaskLogicOperationsBenchmark.intMaskAndNot thrpt 1 30 ops/ms 1024 3767.122 5097.853 1.353 MaskLogicOperationsBenchmark.longMaskAndNot thrpt 1 30 ops/ms 256 7762.614 10534.290 1.357 MaskLogicOperationsBenchmark.longMaskAndNot thrpt 1 30 ops/ms 512 3976.759 5123.445 1.288 MaskLogicOperationsBenchmark.longMaskAndNot thrpt 1 30 ops/ms 1024 1937.389 2573.394 1.328 MaskLogicOperationsBenchmark.shortMaskAndNot thrpt 1 30 ops/ms 256 30165.102 39632.060 1.313 MaskLogicOperationsBenchmark.shortMaskAndNot thrpt 1 30 ops/ms 512 15653.812 20026.600 1.279 MaskLogicOperationsBenchmark.shortMaskAndNot thrpt 1 30 ops/ms 1024 7838.684 10795.177 1.377 MaskLogicOperationsBenchmark.highMaskRegisterPressureWithNots thrpt 1 30 ops/ms 256 20185.546 21548.108 1.067 MaskLogicOperationsBenchmark.highMaskRegisterPressureWithNots thrpt 1 30 ops/ms 512 9549.994 11097.954 1.162 MaskLogicOperationsBenchmark.highMaskRegisterPressureWithNots thrpt 1 30 ops/ms 1024 4797.370 5624.987 1.172 Grace(V2, SVE machine with 128-bit vector length): Benchmark Mode Threads Samples Unit size Before After Gain MaskLogicOperationsBenchmark.byteMaskAndNot thrpt 1 30 ops/ms 256 88221.700 114208.097 1.294 MaskLogicOperationsBenchmark.byteMaskAndNot thrpt 1 30 ops/ms 512 46472.948 64268.305 1.382 MaskLogicOperationsBenchmark.byteMaskAndNot thrpt 1 30 ops/ms 1024 24367.417 33957.434 1.393 MaskLogicOperationsBenchmark.intMaskAndNot thrpt 1 30 ops/ms 256 15774.203 27054.729 1.715 MaskLogicOperationsBenchmark.intMaskAndNot thrpt 1 30 ops/ms 512 7938.354 11484.306 1.446 MaskLogicOperationsBenchmark.intMaskAndNot thrpt 1 30 ops/ms 1024 3973.106 5658.552 1.424 MaskLogicOperationsBenchmark.longMaskAndNot thrpt 1 30 ops/ms 256 7976.768 11533.359 1.445 MaskLogicOperationsBenchmark.longMaskAndNot thrpt 1 30 ops/ms 512 4013.574 5662.615 1.410 MaskLogicOperationsBenchmark.longMaskAndNot thrpt 1 30 ops/ms 1024 2003.350 2810.982 1.403 MaskLogicOperationsBenchmark.shortMaskAndNot thrpt 1 30 ops/ms 256 30464.920 47910.299 1.572 MaskLogicOperationsBenchmark.shortMaskAndNot thrpt 1 30 ops/ms 512 15826.314 23330.242 1.474 MaskLogicOperationsBenchmark.shortMaskAndNot thrpt 1 30 ops/ms 1024 7936.939 11420.379 1.438 MaskLogicOperationsBenchmark.highMaskRegisterPressureWithNots thrpt 1 30 ops/ms 256 17008.969 21002.746 1.234 MaskLogicOperationsBenchmark.highMaskRegisterPressureWithNots thrpt 1 30 ops/ms 512 8159.229 10648.533 1.305 MaskLogicOperationsBenchmark.highMaskRegisterPressureWithNots thrpt 1 30 ops/ms 1024 4004.777 5355.436 1.337 ------------- Commit messages: - 8378737: AArch64: Fix SVE match rule issues for VectorMask.andNot() Changes: https://git.openjdk.org/jdk/pull/30013/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30013&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378737 Stats: 280 lines in 5 files changed: 260 ins; 10 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/30013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30013/head:pull/30013 PR: https://git.openjdk.org/jdk/pull/30013

1 1

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