- core-libs-dev - openjdk.org

RFR: 8376698: Add Spliterator tests for TreeMap sub-maps
by Oli Gillespie 20 Feb '26

20 Feb '26

Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps. Two interesting parts: 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators. 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps. ------------- Commit messages: - Switch to Objects.requireNonNull - Add tests and fix impl Changes: https://git.openjdk.org/jdk/pull/29485/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29485&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376698 Stats: 30 lines in 2 files changed: 29 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29485.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29485/head:pull/29485 PR: https://git.openjdk.org/jdk/pull/29485

4 23

RFR: 8367129: Move input validation checks to Java for java.lang.StringLatin1 intrinsics
by Volkan Yazici 20 Feb '26

20 Feb '26

Moves input validation checks to Java for `java.lang.StringLatin1` intrinsics. While doing so, affected `java.lang.StringUTF16` methods needed to be updated due to relaxed checks at intrinsics. The javadocs of the touched methods are extensively overhauled. ------------- Commit messages: - More doc updates - Reflect that `VerifyIntrinsicChecks` is removed - Merge remote-tracking branch 'upstream/master' into sLatin1Intr - Fix `Helper` - Guard `equals` intrinsic - Cosmetic improvements - Guard `indexOf` intrinsics - Document `StringLatin1` - Guard `inflate`/`compress` intrinsics - Guard `compareTo` intrinsics Changes: https://git.openjdk.org/jdk/pull/28832/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28832&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367129 Stats: 554 lines in 5 files changed: 457 ins; 16 del; 81 mod Patch: https://git.openjdk.org/jdk/pull/28832.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28832/head:pull/28832 PR: https://git.openjdk.org/jdk/pull/28832

5 24

RFR: 8377223: Port fdlibm atanh to Java
by Anton Artemov 20 Feb '26

20 Feb '26

Hi, please consider the following changes: This is a port of FDLIBM atanh method. ------------- Commit messages: - 8377223: Fixed typos. - 8377223: Fixed whitespaces. - 8377223: Fixed whitespaces. - 8377223: Removed commented out line. - 8377223: Port fdlibm atanh to java. Changes: https://git.openjdk.org/jdk/pull/29782/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29782&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377223 Stats: 652 lines in 7 files changed: 646 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29782.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29782/head:pull/29782 PR: https://git.openjdk.org/jdk/pull/29782

4 26

Re: RFR: 8368841: X25519 implementation differs from the specification in RFC 7748 [v3]
by Shawn M Emery 19 Feb '26

19 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 Thank you for the changes. ------------- Marked as reviewed by smemery(a)github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/29750#pullrequestreview-3828946573

1 0

RFR: 8377729: Running jtreg tests with -agent... option causes some tests to fail due to duplicate -agent options provided to a subprocess
by Kirill Shirokov 19 Feb '26

19 Feb '26

The fix removes duplicate `-agent...` and `-javaagent:...` options from test subprocess command line, thus allowing to run jtreg tests with agents that should be specified only once. The fix tested manually: $ make test JTREG="VERBOSE=summary,fail,error" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java" ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR SKIP jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java 1 1 0 0 0 jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java 1 1 0 0 0 jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java 1 1 0 0 0 ============================== TEST SUCCESS $ make test JTREG="VERBOSE=summary,fail,error;JAVA_OPTIONS=-agentpath.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java" ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR SKIP jtreg:test/jdk/sun/tools/jstack/DeadlockDetectionTest.java >> 1 0 1 0 0 << jtreg:test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java >> 1 0 1 0 0 << jtreg:test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java >> 1 0 1 0 0 << ============================== TEST FAILURE $ make test JTREG="VERBOSE=summary,fail,error;VM_OPTIONS=-agentpath:.../async-profiler-binaries/lib/libasyncProfiler.dylib=start,event=cpu,cstack=vm,loglevel=none,flat,file=/dev/null" TEST="test/jdk/sun/tools/jstack/DeadlockDetectionTest.java test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java test/hotspot/jtreg/gc/g1/ihop/TestIHOPStatic.java" (same errors) With the fix everything above passes. Tested on linux-aarch64, macos-aarch64 using specific tests + tier1 suite without additional options. ------------- Commit messages: - 8377729: Running jtreg tests with -agent... option causes some tests to fail due to duplicate -agent options provided to a subprocess Changes: https://git.openjdk.org/jdk/pull/29684/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29684&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377729 Stats: 26 lines in 2 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29684.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29684/head:pull/29684 PR: https://git.openjdk.org/jdk/pull/29684

4 8

RFR: 8376186: [VectorAPI] Nomenclature change for concrete vector classes
by Jatin Bhateja 19 Feb '26

19 Feb '26

As per https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594 on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch. In preparation of Float16 vector API support, changes to nomenclature of concrete vector class by suffixing the vector type with vector bit sizes e.g. FloatVector256 so that we don't end up generating names like Float16256Vector. All existing Vector API jtreg test are passing with the patch. Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - Removing older artifact - 8376186: [VectorAPI] Nomenclature change for concrete vector classes Changes: https://git.openjdk.org/jdk/pull/29614/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29614&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376186 Stats: 74830 lines in 130 files changed: 31372 ins; 31371 del; 12087 mod Patch: https://git.openjdk.org/jdk/pull/29614.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29614/head:pull/29614 PR: https://git.openjdk.org/jdk/pull/29614

3 17

RFR: 8377712: ConstantPool of WeakReferenceKey is not deterministic in CDS archive
by Ioi Lam 19 Feb '26

19 Feb '26

We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic. The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens. The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved. ------------- Commit messages: - 8370855: ConstantPool of WeakReferenceKey is not deterministic in CDS archive Changes: https://git.openjdk.org/jdk/pull/29678/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29678&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377712 Stats: 41 lines in 4 files changed: 39 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29678/head:pull/29678 PR: https://git.openjdk.org/jdk/pull/29678

3 11

Re: RFR: 8377712: ConstantPool of WeakReferenceKey is not deterministic in CDS archive
by Ioi Lam 19 Feb '26

19 Feb '26

On Thu, 12 Feb 2026 05:58:15 GMT, Chen Liang <liach(a)openjdk.org> wrote: >> We are seeing intermittent failures (12 times in Jan 2026) where the CDS archives generated in the JDK build is not deterministic. >> >> The symptom is that (perhaps due to the peculiarity of hash codes and memory addressing??) the constant pool entry for `ReferenceKey<?>` in the `WeakReferenceKey` class is not resolved when the failure happens. Probably it's due to a particular layout in the hashtable such that we have no collisions so the `WeakReferenceKey::equals()` method is never called. >> >> The fix is for the JVM to call a method in `WeakReferenceKey` to force this entry to be resolved. > > Or a better fix would be removing the == path for all reference keys. There's no case where this hits because you are always creating a new strong key. Missing use of class constant means the equals method is completely unused. Thank you @liach @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/29678#issuecomment-3924758708

1 0

RFR: 8326487: ZipFileSystem.getPath("").getFileName() returns null instead of an empty Path
by Jaikiran Pai 19 Feb '26

19 Feb '26

Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8326487? `java.nio.file.Path.getFileName()` is specified to return a non-null value for an empty path. However, the current implementation of zipfs returns null for an empty path. The commit in this PR addresses that issue in zipfs and introduces a test which reproduces the issue and verifies the fix. ------------- Commit messages: - include a test for root path - 8326487: ZipFileSystem.getPath().getFileName() returns null instead of an empty string Changes: https://git.openjdk.org/jdk/pull/29760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29760&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326487 Stats: 46 lines in 2 files changed: 40 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29760.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29760/head:pull/29760 PR: https://git.openjdk.org/jdk/pull/29760

4 9

RFR: 8378110: Add -XX: prefix to settings-file flags in RuntimeMXBean.getInputArguments()
by Oli Gillespie 18 Feb '26

18 Feb '26

Flags passed via a settings file (`.hotspotrc`, or `-XX:Flags=my-file`) do not have the `-XX:` prefix like they would have if passed as command-line args. `JVM_GetVmArguments` then prints these flags also without the prefix, along with command-line flags that _are_ prefixed. However, users of `JVM_GetVmArguments` expect the arguments to be in a format that they can pass as command-line args, for example [in CDS static_dump](https://github.com/openjdk/jdk/blob/63f00fff921ed4ac0f595a0a01… - CDS static_dump currently *does not work* if the main VM uses flags from a settings file. So, always add the `-XX:` prefix to flags from settings files in `JVM_GetVmArguments`. Updated existing test to cover this behaviour. I looked for existing users of `JVM_GetVmArguments` and they either seem like they'll benefit from this change (CDS, JMH via `RuntimeMXBean.getInputArguments()`) or they won't care. **Testing** * Updated the existing InputArgument test with a case that verifies the new behaviour. * Confirmed that CDS static_dump and JMH now work on a VM with flags from a file. ------------- Commit messages: - 8378110: Add -XX: prefix to settings-file flags in RuntimeMXBean.getInputArguments() Changes: https://git.openjdk.org/jdk/pull/29793/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29793&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378110 Stats: 50 lines in 2 files changed: 37 ins; 5 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29793.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29793/head:pull/29793 PR: https://git.openjdk.org/jdk/pull/29793

1 0