- core-libs-dev - openjdk.org

RFR: 8378798: Test tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java failed: missing IOException
by Alexey Semenyuk 27 Feb '26

27 Feb '26

Disable a unit test on Linux: it expects an error condition that is not reliably reproducible. ------------- Commit messages: - CommandOutputControlTest: disable "test_close_streams" test on Linux Changes: https://git.openjdk.org/jdk/pull/29960/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29960&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378798 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29960.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29960/head:pull/29960 PR: https://git.openjdk.org/jdk/pull/29960

2 3

RFR: 8378854: Disable SA tests when ZGC is being used
by Chris Plummer 27 Feb '26

27 Feb '26

We currently problem list all the SA tests when ZGC is being used. However, recently the CR they are problem listed under ([JDK-8307393](https://bugs.openjdk.org/browse/JDK-8307393)) was closed as WNF. Tests are not suppose to be problem listed under closed CRs. The proposed solution is to use the following in all the SA tests: ` * @requires vm.gc != "Z"` Note I kept `serviceability/sa/TestUniverse.java` enabled for ZGC as it was explicitly called out in the problem list comment as a sanity check to keep enabled. While adding the `@requires` I also did some minor cleanup in a few places to keep the `@requires` less cluttered and consistent between tests. Specifically I made it so `@requires vm.hasSA` is always on its own line and always first. Testing in progress. Will cover all tier1 plus tier2, tier3, and tier5 svc testing. ------------- Commit messages: - disable SA tests when using ZGC - disable SA tests when using ZGC Changes: https://git.openjdk.org/jdk/pull/29959/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29959&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378854 Stats: 260 lines in 77 files changed: 94 ins; 91 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/29959.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29959/head:pull/29959 PR: https://git.openjdk.org/jdk/pull/29959

1 0

RFR: 8378792: ObjectMethods.bootstrap missing getter validation
by Chen Liang 27 Feb '26

27 Feb '26

During review of Valhalla lworld vs mainline patch, I noticed Valhalla has a fix for a mainline issue where there is no getter validation for ObjectMethods.bootstrap. We should upstream this fix to mainline to make lworld cleaner and make mainline more robust. Before this fix, the invalid getters caused weird exceptions in method handle construction. Now they consistently throw IllegalArgumentException as specified. ------------- Commit messages: - 8378792: ObjectMethods.bootstrap missing getter validation Changes: https://git.openjdk.org/jdk/pull/29941/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29941&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378792 Stats: 68 lines in 2 files changed: 43 ins; 4 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/29941.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29941/head:pull/29941 PR: https://git.openjdk.org/jdk/pull/29941

3 7

RFR: 8372946 - TreeMap sub-map entry spliterator is expensive
by Oli Gillespie 27 Feb '26

27 Feb '26

`TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough. `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure. This patch fixes the issue by providing a custom spliterator for `EntrySetView`, which is not SIZED. The implementation is copied almost exactly from the equivalent `KeyIterator` classes in this file (`SubMapKeyIterator`, `DescendingSubMapKeyIterator`). The only difference is in `SubMapEntryIterator.getComparator`, for which I copied the implementation from `TreeMap$EntrySpliterator`. Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries. Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow using `IteratorSpliterator`): class java.util.TreeMap$KeySet .stream().limit(1).count() took 0.046ms spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView .stream().limit(1).count() took 218ms spliterator = IteratorSpliterator, estimateSize() = 9999999 After (entrySet is now fast, using `SubMapEntryIterator`): class java.util.TreeMap$KeySet .stream().limit(1).count() took 0.017ms spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView .stream().limit(1).count() took 0.013ms spliterator = SubMapEntryIterator, estimateSize() = 9223372036854775807 ------------- Commit messages: - Attempt to fix 8372946 Changes: https://git.openjdk.org/jdk/pull/28608/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372946 Stats: 70 lines in 1 file changed: 68 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28608/head:pull/28608 PR: https://git.openjdk.org/jdk/pull/28608

2 21

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

Re: RFR: 8368841: X25519 implementation differs from the specification in RFC 7748 [v6]
by Ben Perez 27 Feb '26

27 Feb '26

> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Changed params comparison ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29750/files - new: https://git.openjdk.org/jdk/pull/29750/files/028e5ba0..82416735 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=04-05 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29750.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29750/head:pull/29750 PR: https://git.openjdk.org/jdk/pull/29750

2 1

Re: RFR: 8368841: X25519 implementation differs from the specification in RFC 7748 [v3]
by Anthony Scarpino 27 Feb '26

27 Feb '26

On Thu, 19 Feb 2026 20:03:25 GMT, Ben Perez <bperez(a)openjdk.org> wrote: >> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught. > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > removed parsing functionality in TestXDH that manually clears MSB src/java.base/share/classes/sun/security/ec/XDHPublicKeyImpl.java line 59: > 57: > 58: // RFC 7748 Section 5 requires the MSB of `u` to be zeroed for X25519 > 59: this.u = params.getName().equals("X448") ? u.mod(params.getP()) : I think it would cleaner to compare `NamedParameterSpec` instead of the String. `(paramSpec == NamedParameterSpec.X448) ?`. For here an the other constructor. test/jdk/sun/security/ec/xec/TestXDH.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved. Update the year test/jdk/sun/security/ec/xec/TestXDH.java line 369: > 367: PrivateKey privateKey = kf.generatePrivate(privateSpec); > 368: KeySpec publicSpec = new XECPublicKeySpec(paramSpec, > 369: Convert.hexStringToBigInteger(b_pub)); Can this be replaced with `new BigInteger(b_pub, 16)`? If so, the Convert.java change isn't needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2844074229 PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2844082050 PR Review Comment: https://git.openjdk.org/jdk/pull/29750#discussion_r2844074580

3 5

RFR: 8371438: jpackage should handle the case when "--mac-sign" is specified without signing identity options
by Alexey Semenyuk 27 Feb '26

27 Feb '26

Restore the logic of how jpackage handles cases when the "--mac-sign" option is specified without the "--mac-signing-key-user-name" or "--mac-app-image-sign-identity" option. Make it work as it did prior to the [JDK-8333664](https://bugs.openjdk.org/browse/JDK-8333664) patch, which caused jpackage to silently ignore the "--mac-sign" option and not sign the output bundle. The restored behavior is as follows: If the "--mac-sign" option is specified, jpackage will always attempt to sign the output bundle. If none of the signing identity options ("--mac-signing-key-user-name", "--mac-app-image-sign-identity", or "--mac-installer-sign-identity") is specified, jpackage will look up for a signing identity (or signing identities in case of PKG bundling) in the keychain specified with the "--mac-signing-keychain", or in the default keychain of the current user if the "--mac-signing-keychain" option is not specified. If the keychain contains exactly one signing certificate of a specific type (a certificate for signing an app image or a certificate for signing a PKG installer), jpackage will use it for signing. Otherwise, jpackage will exit with an error. Added tests to cover the cases when the "--mac-sign" option is specified and the keychain has/doesn't have signing certificates. ------------- Commit messages: - Use jdk.test.lib.security.CertificateBuilder to create signing certificates instead of static sign-env.xml - ErrorTest: better coverage for signing without explicit signing identity on the command line - Support signing mocks. So far "/usr/bin/security" mock is supported. - test.mock: enhance CommandAction.Context; MockIllegalStateException: add null check to the ctor - MacSign: expose some API, support keychain mocks - Add negative tests; Fix bug in MacFromOptions.createMacApplicationInternal() uncovered with the negative tests - SigningAppImageTwoStepsTest: remove redundant test cases - MacHelper: Support testing of SHA1 digests with the "--mac-signing-key-user-name" option; reduce number of test cases in th tests derived from the SigningPackageTest test; SigningPackageTest: remove redundant test cases - SigningAppImageTwoStepsTest: add missing MacSign.withKeychain() call. Without the call, the test may randomly fail with cryptic "SigningAppImageTwoStepsTest/test.4fc29fd2/appimage-5/SigningAppImageTwoStepsTest.app/Contents/MacOS/testAL: errSecInternalComponent" error message if the keychain happens to be locked. "security unlock-keychain" command unlocks a keychain, but it gets automatically locked after some duration of time. To avoid interrupts, signing tests should call the "security unlock-keychain" command a keychain before running any signing operations using this keychain. - MacFromOptions: fix ServiceTest failure - ... and 1 more: https://git.openjdk.org/jdk/compare/6b576235...3744639e Changes: https://git.openjdk.org/jdk/pull/29290/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29290&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371438 Stats: 1429 lines in 20 files changed: 1295 ins; 35 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/29290.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29290/head:pull/29290 PR: https://git.openjdk.org/jdk/pull/29290

2 3

Re: RFR: 8368841: X25519 implementation differs from the specification in RFC 7748 [v5]
by Ben Perez 26 Feb '26

26 Feb '26

> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: removed @build statement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29750/files - new: https://git.openjdk.org/jdk/pull/29750/files/e00bd0fe..028e5ba0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29750.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29750/head:pull/29750 PR: https://git.openjdk.org/jdk/pull/29750

1 0

Re: RFR: 8368841: X25519 implementation differs from the specification in RFC 7748 [v4]
by Ben Perez 26 Feb '26

26 Feb '26

> Our implementation of X25519 does not zero the MSB of the `u` coordinate as required by RFC 7748. Currently the test `jdk/sun/security/ec/xec/TestXDH.java` zeroes the bit manually while parsing test vectors, which is likely why this went uncaught. Ben Perez has updated the pull request incrementally with one additional commit since the last revision: moved hexStringToBigInteger from Convert.java to TestXDH.java, no longer clears MSB ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29750/files - new: https://git.openjdk.org/jdk/pull/29750/files/0dd0c9d3..e00bd0fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29750&range=02-03 Stats: 37 lines in 2 files changed: 16 ins; 19 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29750.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29750/head:pull/29750 PR: https://git.openjdk.org/jdk/pull/29750

1 0