- core-libs-dev - openjdk.org

RFR: 8378702: jdk.test.lib.Platform.isMusl() may return false negative on Alpine Linux
by Frederic Thevenet 02 Mar '26

02 Mar '26

jdk.test.lib.Platform.isMusl() may return false on Alpine linux, where it should return true. This means that the jtreg tests is is used to guard will incorrectly fail. This happens when tests deliberately clobber the PATH and `ldd` can no longer be found. This PR uses a full path for `ldd` instead to work around the issue. ------------- Commit messages: - 8378702: jdk.test.lib.Platform.isMusl() may return false negative on Alpine Linux Changes: https://git.openjdk.org/jdk/pull/29923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29923&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378702 Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29923/head:pull/29923 PR: https://git.openjdk.org/jdk/pull/29923

5 14

RFR: 8378111: Migrate java/util/jar tests to JUnit
by Justin Lu 02 Mar '26

02 Mar '26

This PR migrates the java/util/jar tests to use _JUnit_. https://github.com/openjdk/jdk/commit/afe0aeee746bccbbe4bc6c9a8cd2302228ecc… includes changes for _testNG_ based tests. https://github.com/openjdk/jdk/commit/c5a7f75840f96fa77ec3ed7faa713990adb84… includes changes for `main` based tests. Before: Framework-based tests: 125 = 125 TestNG + 0 JUnit. After: Framework-based tests: 174 = 0 TestNG + 174 JUnit ------------- Commit messages: - main -> JUnit - TestNG -> JUnit Changes: https://git.openjdk.org/jdk/pull/29828/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378111 Stats: 917 lines in 33 files changed: 283 ins; 169 del; 465 mod Patch: https://git.openjdk.org/jdk/pull/29828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29828/head:pull/29828 PR: https://git.openjdk.org/jdk/pull/29828

6 17

RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas, take 2
by Peter Levart 02 Mar '26

02 Mar '26

Hi, When administering my mailing lists, my attention was drawn to this pull request: https://github.com/openjdk/jdk/pull/28575, which tries to tackle this scaling problem. Although it was dismissed, I remembered that I was dealing with a similar problem in the past, so I looked closely... Here's an alternative take at the problem. It reuses a maintained public component of JDK, the LongAdder, so in this respect, it does not add complexity and maintainance burden. It also does not change the internal API of the MemorySessionImpl. The size of the patch is also smaller. For experimenting and benchmarking, I created a separate impmenetation of just the acquire/release/close logic with existing "simple" and this new "striped" implementations here: https://github.com/plevart/acquire-release-close Running it on my 8 core (16 threads) Linux PC, it gives promising results without regression for single-threaded use: ** Simple, measure run #1... concurrency: 1, nanos: 39909697 (x 1.0) concurrency: 2, nanos: 164735444 (x 4.127704702944751) concurrency: 4, nanos: 394283724 (x 9.87939657873123) concurrency: 8, nanos: 672278915 (x 16.84500172978011) concurrency: 16, nanos: 2169282886 (x 54.3547821473062) ** Simple, measure run #2... concurrency: 1, nanos: 40318379 (x 1.0) concurrency: 2, nanos: 163438657 (x 4.053701092496799) concurrency: 4, nanos: 399382210 (x 9.905710991009832) concurrency: 8, nanos: 694862623 (x 17.23438888750959) concurrency: 16, nanos: 2182386494 (x 54.12882531810121) ** Simple, measure run #3... concurrency: 1, nanos: 39871197 (x 1.0) concurrency: 2, nanos: 168843686 (x 4.234728292707139) concurrency: 4, nanos: 375489497 (x 9.417562683156966) concurrency: 8, nanos: 675885694 (x 16.951728186138983) concurrency: 16, nanos: 2083500812 (x 52.255787856080666) ** end. ** Striped, measure run #1... concurrency: 1, nanos: 36698350 (x 1.0) concurrency: 2, nanos: 47349695 (x 1.290240433152989) concurrency: 4, nanos: 58622304 (x 1.5974098018030782) concurrency: 8, nanos: 60548173 (x 1.6498881557345222) concurrency: 16, nanos: 70607406 (x 1.9239940215295783) ** Striped, measure run #2... concurrency: 1, nanos: 37217044 (x 1.0) concurrency: 2, nanos: 38610020 (x 1.0374284427317764) concurrency: 4, nanos: 39166893 (x 1.0523912914738742) concurrency: 8, nanos: 51778829 (x 1.3912665659314587) concurrency: 16, nanos: 70277394 (x 1.8883120862581133) ** Striped, measure run #3... concurrency: 1, nanos: 37589735 (x 1.0) concurrency: 2, nanos: 38748261 (x 1.0308202758013592) concurrency: 4, nanos: 38656911 (x 1.0283900910714054) concurrency: 8, nanos: 40530711 (x 1.0782388064188269) concurrency: 16, nanos: 52545852 (x 1.3978776918751887) ** end. ------------- Commit messages: - 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas, take 2 Changes: https://git.openjdk.org/jdk/pull/29866/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29866&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371260 Stats: 62 lines in 3 files changed: 32 ins; 13 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29866.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29866/head:pull/29866 PR: https://git.openjdk.org/jdk/pull/29866

2 5

RFR: 8378963: Test test/jdk/java/lang/management/RuntimeMXBean/InputArgument.java#id4 failed
by Oli Gillespie 02 Mar '26

02 Mar '26

When running the test with an explicit garbage collector flag (that isn't ParallelGC), this test would fail with: Error occurred during initialization of VM Multiple garbage collectors selected Instead of using `@requires` to limit the test compatibility, I switched the test to use more innocuous flags that a) are unlikely to be set for test purposes and b) can be harmlessly set multiple times. The exact flags are not relevant to the test, we're just testing that the `-XX:` prefix is added. ------------- Commit messages: - Fix test Changes: https://git.openjdk.org/jdk/pull/29999/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29999&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378963 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29999/head:pull/29999 PR: https://git.openjdk.org/jdk/pull/29999

2 1

RFR: 8378180: Compiling OpenJDK with C23 C-Compiler gives warning: initialization discards ‘const’ qualifier from pointer target type
by Jasmine Karthikeyan 02 Mar '26

02 Mar '26

Hi all, this is a quick patch to fix a build issue I encountered when updating my Linux system. [Glibc 2.43](https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html) changes the definition of some string related functions to return `const char*` when provided a `const char*` parameter, rather than the previous behavior of returning `char*`. I've fixed this by applying the `const` modifier, and casting to `char*` when needed. This should be backwards-compatible since assigning a non-const pointer to const is an implicit conversion. Thoughts and comments would be appreciated on whether this is the best way to fix this issue. Thanks! ------------- Commit messages: - Fix discarded const qualifiers Changes: https://git.openjdk.org/jdk/pull/29929/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29929&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378180 Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/29929.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29929/head:pull/29929 PR: https://git.openjdk.org/jdk/pull/29929

3 2

RFR: 8378833: Improve offset arithmetic in ArraysSupport::mismatch
by Raffaello Giulietti 01 Mar '26

01 Mar '26

Some of the `ArraysSupport::mismatch` family of methods compute offsets using a mix of `int` and `long` arithmetic. This can lead to wrong results, which are then passed as arguments to an intrinsic method or to a Java method using `Unsafe`. ------------- Commit messages: - 8378833: Improve offset arithmetic in ArraysSupport::mismatch Changes: https://git.openjdk.org/jdk/pull/29957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378833 Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29957/head:pull/29957 PR: https://git.openjdk.org/jdk/pull/29957

4 4

8377939: Improving efficiency of StreamEncoder::append(CharSequence) and StreamEncoder::(CharSequence, int, int)
by Markus KARG 01 Mar '26

01 Mar '26

Core-Lib Devs, as proposed in https://bugs.openjdk.org/browse/JDK-8377939 I would like to improve efficiency of StreamEncoder::append(CharSequence) (and in turn OutputStreamWriter::append(CharSequence)) for non-String and non-CharBuffer values, which seems to be safe and simple: * No API or behavior is changed. * StreamEncoder is final and is only used internally of OpenJDK, and is not leaked. * AFAIK the proposed change has no side effects other than being potentially more efficient. * Only few classes make actual use of StreamEncoder; OutputStreamWriter is probably the most popular one, and immediately provides potential benefit to I/O-bound applications dealing with StringBuilder-crafted output. I have meanwhile coded the change (see diff at https://github.com/openjdk/jdk/compare/master...mkarg:jdk:StreamEncoder-use…) and tested it successfully using OpenJDK Github Actions (see result at https://github.com/mkarg/jdk/actions/runs/22259626078) Are you fine with me opening a Pull Request on Github? Thanks! -Markus

1 1

RFR: 8377923: Add anchors to the options in the Tools man pages
by Roger Calnan 28 Feb '26

28 Feb '26

adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option ------------- Commit messages: - removed link to option already covered by -feedback - clean up verbose options - only link one of the verbose options - removed links for some common options - initial update to options - Update full name Changes: https://git.openjdk.org/jdk/pull/29979/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29979&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377923 Stats: 84 lines in 6 files changed: 0 ins; 0 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/29979.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29979/head:pull/29979 PR: https://git.openjdk.org/jdk/pull/29979

1 0

RFR: 8377921: Add anchors to the options in the Core Libs tool man pages
by Roger Calnan 28 Feb '26

28 Feb '26

adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option ------------- Commit messages: - removed linking for --version - update compress option - initial update to man pages - Update full name Changes: https://git.openjdk.org/jdk/pull/29978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377921 Stats: 35 lines in 2 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/29978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29978/head:pull/29978 PR: https://git.openjdk.org/jdk/pull/29978

1 0

RFR: 8377992: (zipfs) Align ZipFileSystem END header validation with the ZipFile implementation
by Eirik Bjørsnøs 28 Feb '26

28 Feb '26

Please review this PR which brings `jdk.nio.zipfs.ZipFileSystem` `END` header validation into behavioral alignment with the corresponding checks in `java.util.zip.ZipFile`. This brings two validation checks over to `ZipFileSystem`: * Rejection of END headers with a CEN size larger than `ArraysSupport.SOFT_MAX_ARRAY_LENGTH` (JDK-8272746) * Rejection of END headers with a total entry count which cannot fit within the CEN byte array (JDK-8341625) The test `test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java` is updated to to verify that ZIP files rejected by the `ZipFile` constructor are now also rejected by `ZipFileSystem.newFileSystem`. Tangentially, `ZipFileSystem.findEND` is updated to make `END.centot` a `long` instead of an `int`. This avoids a narrowing conversion which otherwise prevents validating a larger than Integer.MAX_VALUE number of CEN entries. Similar adjustments to `ZipFile` was done in JDK-8341625. `ZipFile.Source.initCEN` is updated with some minor code style / code comment changes to make side-by-side diffs less noisy. Additionally, validated `end.cenlen` and `end.centot` values are now consistently converted to `int` using `Math.toIntExact`. ------------- Commit messages: - Fix merge commit - Merge branch 'master' into zipfs-endofcen-validation - Realign comment whitespace - Use Math.toIntExact once in End::write - Align ZipFileSystem END header validation with the ZipFile validation Changes: https://git.openjdk.org/jdk/pull/29747/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29747&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377992 Stats: 85 lines in 3 files changed: 42 ins; 16 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/29747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29747/head:pull/29747 PR: https://git.openjdk.org/jdk/pull/29747

2 13