From swen at openjdk.org Mon Sep 1 05:57:50 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 1 Sep 2025 05:57:50 GMT Subject: Integrated: 8365620: Using enhanced switch in MethodHandleDesc In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 04:49:28 GMT, Shaojin Wen wrote: > In MethodHandleDesc, the `ofField` method uses enhanced switch, while the `of` and `ofMethod` methods use traditional switch. The same class should have a unified style. This pull request has now been integrated. Changeset: a668f437 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/a668f437e481d02cbb82d4f40dd14ec3a6036399 Stats: 26 lines in 1 file changed: 0 ins; 14 del; 12 mod 8365620: Using enhanced switch in MethodHandleDesc Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/26769 From amitkumar at openjdk.org Mon Sep 1 06:23:52 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 1 Sep 2025 06:23:52 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() Message-ID: Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): java/foreign/TestFill.java java/foreign/TestSegments.java java/foreign/TestSegmentBulkOperationsContentHash.java java/foreign/TestStringEncoding.java java/foreign/TestVarArgs.java ```java // Always allocate at least some memory so that zero-length segments have distinct // non-zero addresses. alignedSize = Math.max(1, alignedSize); Here minimum-allocated size will be 1, which is incorrect because private static void initNativeMemory(long address, long byteSize) { for (long i = 0; i < byteSize; i += Long.BYTES) { UNSAFE.putLongUnaligned(null, address + i, 0); } } `initNativeMemory()` is going to write Long. ------------- Commit messages: - update min size to Long.BYTES Changes: https://git.openjdk.org/jdk/pull/27027/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27027&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366495 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27027/head:pull/27027 PR: https://git.openjdk.org/jdk/pull/27027 From shade at openjdk.org Mon Sep 1 06:28:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 1 Sep 2025 06:28:51 GMT Subject: RFR: 8345810: Custom launchers must be linked with pthread to avoid dynamic linker issues [v2] In-Reply-To: References: Message-ID: <-z8XkGE4okfywDA7MQUq2Or9zZPCSO5EilCgNmtdMJU=.f0c7d5cf-f2cc-4c57-970c-1cd1362c8e88@github.com> On Thu, 28 Aug 2025 15:10:03 GMT, Aleksey Shipilev wrote: >> See the bug for more investigation. >> >> The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`. >> >> Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason. >> >> Additional testing: >> - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote`, 100x, no failures >> - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures >> - [x] Linux AArch64 server fastdebug, `jdk_all`, no failures > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Broader pthread linkage for all JDK jtreg executables, similar to how Hotspot jtreg executables do it > - Merge branch 'master' into JDK-8345810-custom-launcher-dlerror > - Change to LIB* variables > - Fix Thanks all! Here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26978#issuecomment-3241009356 From shade at openjdk.org Mon Sep 1 06:28:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 1 Sep 2025 06:28:53 GMT Subject: Integrated: 8345810: Custom launchers must be linked with pthread to avoid dynamic linker issues In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 07:43:19 GMT, Aleksey Shipilev wrote: > See the bug for more investigation. > > The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`. > > Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason. > > Additional testing: > - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote`, 100x, no failures > - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures > - [x] Linux AArch64 server fastdebug, `jdk_all`, no failures This pull request has now been integrated. Changeset: 685da032 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/685da0323b27abda5ab0484f4c8abaaeeff882ea Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod 8345810: Custom launchers must be linked with pthread to avoid dynamic linker issues Reviewed-by: asemenyuk, erikj, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26978 From pminborg at openjdk.org Mon Sep 1 07:50:46 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 1 Sep 2025 07:50:46 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 05:31:43 GMT, Amit Kumar wrote: > Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 > > These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): > > java/foreign/TestFill.java > java/foreign/TestSegments.java > java/foreign/TestSegmentBulkOperationsContentHash.java > java/foreign/TestStringEncoding.java > java/foreign/TestVarArgs.java > > > > ```java > // Always allocate at least some memory so that zero-length segments have distinct > // non-zero addresses. > alignedSize = Math.max(1, alignedSize); > > > Here minimum-allocated size will be 1, which is incorrect because > > > private static void initNativeMemory(long address, long byteSize) { > for (long i = 0; i < byteSize; i += Long.BYTES) { > UNSAFE.putLongUnaligned(null, address + i, 0); > } > } > > `initNativeMemory()` is going to write Long. Thanks for spotting this bug! It seems like a bug that I introduced, and so, thanks again! ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27027#pullrequestreview-3172497772 From jpai at openjdk.org Mon Sep 1 07:55:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Sep 2025 07:55:42 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 05:31:43 GMT, Amit Kumar wrote: > Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 > > These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): > > java/foreign/TestFill.java > java/foreign/TestSegments.java > java/foreign/TestSegmentBulkOperationsContentHash.java > java/foreign/TestStringEncoding.java > java/foreign/TestVarArgs.java > > > > ```java > // Always allocate at least some memory so that zero-length segments have distinct > // non-zero addresses. > alignedSize = Math.max(1, alignedSize); > > > Here minimum-allocated size will be 1, which is incorrect because > > > private static void initNativeMemory(long address, long byteSize) { > for (long i = 0; i < byteSize; i += Long.BYTES) { > UNSAFE.putLongUnaligned(null, address + i, 0); > } > } > > `initNativeMemory()` is going to write Long. Hello Amit, would it be possible to add a jtreg test for this? Do you know what was the code path or values for the `allocateNativeSegment()` call which triggered this issue. Having that replicated in a regression test I think would prevent this from happening again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27027#issuecomment-3241265723 From jpai at openjdk.org Mon Sep 1 08:05:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Sep 2025 08:05:55 GMT Subject: RFR: 8359174: tools/jlink/JLink20000Packages.java timed out [v7] In-Reply-To: <4YaqAT65lxqBB13eoVrI6hNzPogClmy5oZN_j6xv2xo=.3facf047-f6cf-4d60-b54c-804cb46a30ba@github.com> References: <4YaqAT65lxqBB13eoVrI6hNzPogClmy5oZN_j6xv2xo=.3facf047-f6cf-4d60-b54c-804cb46a30ba@github.com> Message-ID: On Fri, 1 Aug 2025 18:03:52 GMT, Henry Jen wrote: >> Create a jar directly from the memory instead of real file, this should reduce the I/O overhead which likely the reason for the time out. >> The issue is not reproducible locally, and fails intermittently, so we simply trying to reduce time needed. >> The jar file created is verified manually running jtreg with retain=all. > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge openjdk/master' into JDK-8359174 > - Clean up module dependencies > - Clean up jtreg directives > - Adapt review feedbacks > - Update copyright year > - Update copyright year > - cleanup > - 8359174: tools/jlink/JLink20000Packages.java timed out The updated changes look good to me. Thank you Henry. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25981#pullrequestreview-3172545488 From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From galder at openjdk.org Mon Sep 1 08:19:44 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 1 Sep 2025 08:19:44 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v4] In-Reply-To: <0VA9QnuPSb55PbioO1XWtSmrAC-sQet0hb_ldRgKdFQ=.95f56a0b-3b08-4654-8f1e-7217cd9bcabe@github.com> References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <0VA9QnuPSb55PbioO1XWtSmrAC-sQet0hb_ldRgKdFQ=.95f56a0b-3b08-4654-8f1e-7217cd9bcabe@github.com> Message-ID: <5xrZ-TcQ9OaMFIAMGIMTDCwGdexIMs0eJd6Li-T1aQc=.fc863cb9-0ce2-488f-a7d6-3aa211248798@github.com> On Wed, 27 Aug 2025 09:56:29 GMT, Emanuel Peter wrote: > Can you find out why we don't vectorize with AVX1 here? This was a fun little rabbit hole. The explanation below is for `test6` but I think the same logic applies to `test9`: The problem comes from the IR node definition, what JTreg does with that, and the what HotSpot code actually does. The annotation definition is: @IR(counts = {IRNode.LOAD_VECTOR_F, "> 0", So JTreg assumes that the regex should match a vector size of 8. With `UseAVX=1` and floats, `IRNode.getMaxElementsForTypeOnX86` returns 8 and so that's how the constraint is set: * Constraint 1: "(\d+(\s){2}(LoadVector.*)+(\s){2}===.*vector[A-Za-z])" But the issue is that at runtime the vector size is 4: 844 LoadVector === ... #vectorx HotSpot logic is more nuanced, with the key being what happens in `SuperWord::unrolling_analysis`. The thing that JTreg doesn't know is that there are 2 types involved in the loop, float **and** int: for (int i = 0; i < a.length; i++) { a[i] = Float.floatToRawIntBits(b[i]); } With `UseAVX=1`, the max vector size for floats is 8, but for ints is 4. So the JVM picks the minimum value and uses that. Hence that is how unrolling is 4... all the way to the load vector size which is 4. IMO the right thing to do would be to fix the annotation to be: @IR(counts = {IRNode.LOAD_VECTOR_F, IRNode.VECTOR_SIZE_4, "> 0", And explain it in javadoc why the expected size is 4. The same with `test9` WDYT @eme64? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3241348514 From epeter at openjdk.org Mon Sep 1 08:43:44 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 1 Sep 2025 08:43:44 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v4] In-Reply-To: <5xrZ-TcQ9OaMFIAMGIMTDCwGdexIMs0eJd6Li-T1aQc=.fc863cb9-0ce2-488f-a7d6-3aa211248798@github.com> References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <0VA9QnuPSb55PbioO1XWtSmrAC-sQet0hb_ldRgKdFQ=.95f56a0b-3b08-4654-8f1e-7217cd9bcabe@github.com> <5xrZ-TcQ9OaMFIAMGIMTDCwGdexIMs0eJd6Li-T1aQc=.fc863cb9-0ce2-488f-a7d6-3aa211248798@github.com> Message-ID: On Mon, 1 Sep 2025 08:17:08 GMT, Galder Zamarre?o wrote: >> @galderz I got a failure in out testing: >> >> With VM flag: `-XX:UseAVX=1`. >> >> >> Failed IR Rules (2) of Methods (2) >> ---------------------------------- >> 1) Method "static java.lang.Object[] compiler.loopopts.superword.TestCompatibleUseDefTypeSize.test6(int[],float[])" - [Failed IR rules: 1]: >> * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"sse4.1", "true", "asimd", "true", "rvv", "true"}, counts={"_#V#LOAD_VECTOR_F#_", "> 0", "_#STORE_VECTOR#_", "> 0", "_#VECTOR_REINTERPRET#_", "> 0"}, applyIfPlatformOr={}, applyIfPlatform={"64-bit", "true"}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" >> > Phase "PrintIdeal": >> - counts: Graph contains wrong number of nodes: >> * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z])" >> - Failed comparison: [found] 0 > 0 [given] >> - No nodes matched! >> >> 2) Method "static java.lang.Object[] compiler.loopopts.superword.TestCompatibleUseDefTypeSize.test9(long[],double[])" - [Failed IR rules: 1]: >> * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"sse4.1", "true", "asimd", "true", "rvv", "true"}, counts={"_#V#LOAD_VECTOR_D#_", "> 0", "_#STORE_VECTOR#_", "> 0", "_#VECTOR_REINTERPRET#_", "> 0"}, applyIfPlatformOr={}, applyIfPlatform={"64-bit", "true"}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" >> > Phase "PrintIdeal": >> - counts: Graph contains wrong number of nodes: >> * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z])" >> - Failed comparison: [found] 0 > 0 [given] >> - No nodes matched! >> >> >> I suspect that `test6` with `floatToRawIntBits` and `test9` with `doubleToRawLongBits` are only supported with `AVX2`. Question is if that is really supposed to be like that, or if we should even file an RFE to extend support for `AVX1` and lower. >> >> Can you find out why we don't vectorize with `AVX1` here? > >> Can you find out why we don't vectorize with AVX1 here? > > This was a fun little rabbit hole. The explanation below is for `test6` but I think the same logic applies to `test9`: > > The problem comes from the IR node definition, what JTreg does with that, and the what HotSpot code actually does. > > The annotation definition is: > > @IR(counts = {IRNode.LOAD_VECTOR_F, "> 0", > > > So JTreg assumes that the regex should match a vector size of 8. With `UseAVX=1` and floats, `IRNode.getMaxElementsForTypeOnX86` returns 8 and so that's how the constraint is set: > > > * Constraint 1: "(\d+(\s){2}(LoadVector.*)+(\s){2}===.*vector[A-Za-z])" > > > But the issue is that at runtime the vector size is 4: > > 844 LoadVector === ... #vectorx > > > HotSpot logic is more nuanced, with the key being what happens in `SuperWord::unrolling_analysis`. The thing that JTreg doesn't know is that there are 2 types involved in the loop, float **and** int: > > > for (int i = 0; i < a.length; i++) { > a[i] = Float.floatToRawIntBits(b[i]); > } > > > With `UseAVX=1`, the max vector size for floats is 8, but for ints is 4. So the JVM picks the minimum value and uses that. Hence that is how unrolling is 4... all the way to the load vector size which is 4. > > IMO the right thing to do would be to fix the annotation to be: > > > @IR(counts = {IRNode.LOAD_VECTOR_F, IRNode.VECTOR_SIZE_4, "> 0", > > > And explain it in javadoc why the expected size is 4. > > The same with `test9` > > WDYT @eme64? @galderz Ah, maybe we just need to do it like here then: `test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java:192:50: counts = {IRNode.VECTOR_CAST_I2F, IRNode.VECTOR_SIZE + "min(max_int, max_float)", ">0"})` When doing cast/reinterpret/move between types this always happens ;) I think this should generalize over all platforms. Does that work? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3241438142 From epeter at openjdk.org Mon Sep 1 08:47:51 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 1 Sep 2025 08:47:51 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v5] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: <8_JXUPiLQNWEmDTbAnwB1jdYu6mTE3_NbETZkQabPwU=.78227d3e-8312-47da-bb2b-0a84017fc724@github.com> On Mon, 25 Aug 2025 07:13:43 GMT, Galder Zamarre?o wrote: >> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations. >> >> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows: >> >> >> Benchmark (seed) (size) Mode Cnt Base Patch Units Diff >> VectorBitConversion.doubleToLongBits 0 2048 thrpt 8 1168.782 1157.717 ops/ms -1% >> VectorBitConversion.doubleToRawLongBits 0 2048 thrpt 8 3999.387 7353.936 ops/ms +83% >> VectorBitConversion.floatToIntBits 0 2048 thrpt 8 1200.338 1188.206 ops/ms -1% >> VectorBitConversion.floatToRawIntBits 0 2048 thrpt 8 4058.248 14792.474 ops/ms +264% >> VectorBitConversion.intBitsToFloat 0 2048 thrpt 8 3050.313 14984.246 ops/ms +391% >> VectorBitConversion.longBitsToDouble 0 2048 thrpt 8 3022.691 7379.360 ops/ms +144% >> >> >> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control. >> >> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions. > > Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Merge branch 'master' into topic.fp-bits-vector > - Add more IR node positive assertions > - Fix source of data for benchmarks > - Refactor benchmarks to TypeVectorOperations > - Check at the very least that auto vectorization is supported > - Avoid VectorReinterpret::implemented > - Refactor and add copyright header > - Rephrase comment > - Removed unnecessary assert methods > - Adjust IR test after adding Move* vector support > - ... and 12 more: https://git.openjdk.org/jdk/compare/fc6e0b6f...e7e4d801 test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java line 460: > 458: @IR(counts = {IRNode.LOAD_VECTOR_L, "> 0", > 459: IRNode.STORE_VECTOR, "> 0", > 460: IRNode.VECTOR_REINTERPRET, "> 0"}, Ah, I just saw that `VECTOR_REINTERPRET` is no `vectorNode`, so we don't check the size for it. Would it have a type and size though? If so, we could consider making it more precise, like all the vector casts. Would be a little bit of work, but it would make the rules more precise. Could also be a separate RFE. 2458 public static final String VECTOR_REINTERPRET = PREFIX + "VECTOR_REINTERPRET" + POSTFIX; 2459 static { 2460 beforeMatchingNameRegex(VECTOR_REINTERPRET, "VectorReinterpret"); 2461 } 2462 2463 public static final String VECTOR_UCAST_B2S = VECTOR_PREFIX + "VECTOR_UCAST_B2S" + POSTFIX; 2464 static { 2465 vectorNode(VECTOR_UCAST_B2S, "VectorUCastB2X", TYPE_SHORT); 2466 } Depending on the dump, it may not be so easy though. Not sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2313298675 From galder at openjdk.org Mon Sep 1 08:51:51 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 1 Sep 2025 08:51:51 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v5] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: On Mon, 25 Aug 2025 07:13:43 GMT, Galder Zamarre?o wrote: >> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations. >> >> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows: >> >> >> Benchmark (seed) (size) Mode Cnt Base Patch Units Diff >> VectorBitConversion.doubleToLongBits 0 2048 thrpt 8 1168.782 1157.717 ops/ms -1% >> VectorBitConversion.doubleToRawLongBits 0 2048 thrpt 8 3999.387 7353.936 ops/ms +83% >> VectorBitConversion.floatToIntBits 0 2048 thrpt 8 1200.338 1188.206 ops/ms -1% >> VectorBitConversion.floatToRawIntBits 0 2048 thrpt 8 4058.248 14792.474 ops/ms +264% >> VectorBitConversion.intBitsToFloat 0 2048 thrpt 8 3050.313 14984.246 ops/ms +391% >> VectorBitConversion.longBitsToDouble 0 2048 thrpt 8 3022.691 7379.360 ops/ms +144% >> >> >> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control. >> >> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions. > > Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Merge branch 'master' into topic.fp-bits-vector > - Add more IR node positive assertions > - Fix source of data for benchmarks > - Refactor benchmarks to TypeVectorOperations > - Check at the very least that auto vectorization is supported > - Avoid VectorReinterpret::implemented > - Refactor and add copyright header > - Rephrase comment > - Removed unnecessary assert methods > - Adjust IR test after adding Move* vector support > - ... and 12 more: https://git.openjdk.org/jdk/compare/54d7c4b3...e7e4d801 One correction about my suggested fix above: This one would work for `UseAVX=1` but would fail with other `UseAVX` values. @IR(counts = {IRNode.LOAD_VECTOR_F, IRNode.VECTOR_SIZE_4, "> 0", It would need to be something like this to work in all cases: @IR(counts = {IRNode.LOAD_VECTOR_F, IRNode.VECTOR_SIZE_ANY, "> 0", ------------- PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3241465858 From galder at openjdk.org Mon Sep 1 09:03:24 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 1 Sep 2025 09:03:24 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v6] In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: > I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations. > > Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows: > > > Benchmark (seed) (size) Mode Cnt Base Patch Units Diff > VectorBitConversion.doubleToLongBits 0 2048 thrpt 8 1168.782 1157.717 ops/ms -1% > VectorBitConversion.doubleToRawLongBits 0 2048 thrpt 8 3999.387 7353.936 ops/ms +83% > VectorBitConversion.floatToIntBits 0 2048 thrpt 8 1200.338 1188.206 ops/ms -1% > VectorBitConversion.floatToRawIntBits 0 2048 thrpt 8 4058.248 14792.474 ops/ms +264% > VectorBitConversion.intBitsToFloat 0 2048 thrpt 8 3050.313 14984.246 ops/ms +391% > VectorBitConversion.longBitsToDouble 0 2048 thrpt 8 3022.691 7379.360 ops/ms +144% > > > The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control. > > I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions. Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: Adjust vector size expectations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26457/files - new: https://git.openjdk.org/jdk/pull/26457/files/e7e4d801..632408ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26457&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26457&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26457.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26457/head:pull/26457 PR: https://git.openjdk.org/jdk/pull/26457 From galder at openjdk.org Mon Sep 1 09:03:25 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 1 Sep 2025 09:03:25 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v4] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <0VA9QnuPSb55PbioO1XWtSmrAC-sQet0hb_ldRgKdFQ=.95f56a0b-3b08-4654-8f1e-7217cd9bcabe@github.com> <5xrZ-TcQ9OaMFIAMGIMTDCwGdexIMs0eJd6Li-T1aQc=.fc863cb9-0ce2-488f-a7d6-3aa211248798@github.com> Message-ID: On Mon, 1 Sep 2025 08:40:52 GMT, Emanuel Peter wrote: > Does that work? Yeah that works, I'll push an update shortly @eme64 I've just pushed an update that fixes the vector size expectations. I didn't end up writing a javadoc since the proposed solution makes it clearer what the expected size should be. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3241495486 PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3241505284 From galder at openjdk.org Mon Sep 1 09:03:28 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 1 Sep 2025 09:03:28 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v5] In-Reply-To: <8_JXUPiLQNWEmDTbAnwB1jdYu6mTE3_NbETZkQabPwU=.78227d3e-8312-47da-bb2b-0a84017fc724@github.com> References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <8_JXUPiLQNWEmDTbAnwB1jdYu6mTE3_NbETZkQabPwU=.78227d3e-8312-47da-bb2b-0a84017fc724@github.com> Message-ID: On Mon, 1 Sep 2025 08:44:10 GMT, Emanuel Peter wrote: >> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: >> >> - Merge branch 'master' into topic.fp-bits-vector >> - Add more IR node positive assertions >> - Fix source of data for benchmarks >> - Refactor benchmarks to TypeVectorOperations >> - Check at the very least that auto vectorization is supported >> - Avoid VectorReinterpret::implemented >> - Refactor and add copyright header >> - Rephrase comment >> - Removed unnecessary assert methods >> - Adjust IR test after adding Move* vector support >> - ... and 12 more: https://git.openjdk.org/jdk/compare/57cf332d...e7e4d801 > > test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java line 460: > >> 458: @IR(counts = {IRNode.LOAD_VECTOR_L, "> 0", >> 459: IRNode.STORE_VECTOR, "> 0", >> 460: IRNode.VECTOR_REINTERPRET, "> 0"}, > > Ah, I just saw that `VECTOR_REINTERPRET` is no `vectorNode`, so we don't check the size for it. Would it have a type and size though? > > If so, we could consider making it more precise, like all the vector casts. > Would be a little bit of work, but it would make the rules more precise. > Could also be a separate RFE. > > > 2458 public static final String VECTOR_REINTERPRET = PREFIX + "VECTOR_REINTERPRET" + POSTFIX; > 2459 static { > 2460 beforeMatchingNameRegex(VECTOR_REINTERPRET, "VectorReinterpret"); > 2461 } > 2462 > 2463 public static final String VECTOR_UCAST_B2S = VECTOR_PREFIX + "VECTOR_UCAST_B2S" + POSTFIX; > 2464 static { > 2465 vectorNode(VECTOR_UCAST_B2S, "VectorUCastB2X", TYPE_SHORT); > 2466 } > > > Depending on the dump, it may not be so easy though. Not sure. That makes sense, I'll create a separate RFE for that ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2313333399 From duke at openjdk.org Mon Sep 1 09:06:56 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Sep 2025 09:06:56 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants Message-ID: In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. Passes tests in `jdk/classfile`. ------------- Commit messages: - nn - Merge branch 'master' into JDK-8354871 - constants Changes: https://git.openjdk.org/jdk/pull/27029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354871 Stats: 124 lines in 7 files changed: 21 ins; 26 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/27029.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27029/head:pull/27029 PR: https://git.openjdk.org/jdk/pull/27029 From epeter at openjdk.org Mon Sep 1 09:12:44 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 1 Sep 2025 09:12:44 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v6] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: On Mon, 1 Sep 2025 09:03:24 GMT, Galder Zamarre?o wrote: >> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations. >> >> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows: >> >> >> Benchmark (seed) (size) Mode Cnt Base Patch Units Diff >> VectorBitConversion.doubleToLongBits 0 2048 thrpt 8 1168.782 1157.717 ops/ms -1% >> VectorBitConversion.doubleToRawLongBits 0 2048 thrpt 8 3999.387 7353.936 ops/ms +83% >> VectorBitConversion.floatToIntBits 0 2048 thrpt 8 1200.338 1188.206 ops/ms -1% >> VectorBitConversion.floatToRawIntBits 0 2048 thrpt 8 4058.248 14792.474 ops/ms +264% >> VectorBitConversion.intBitsToFloat 0 2048 thrpt 8 3050.313 14984.246 ops/ms +391% >> VectorBitConversion.longBitsToDouble 0 2048 thrpt 8 3022.691 7379.360 ops/ms +144% >> >> >> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control. >> >> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions. > > Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: > > Adjust vector size expectations Perfect, thanks for the update! I'll submit testing again :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3241529779 From epeter at openjdk.org Mon Sep 1 09:12:46 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 1 Sep 2025 09:12:46 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v5] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <8_JXUPiLQNWEmDTbAnwB1jdYu6mTE3_NbETZkQabPwU=.78227d3e-8312-47da-bb2b-0a84017fc724@github.com> Message-ID: On Mon, 1 Sep 2025 09:07:46 GMT, Galder Zamarre?o wrote: >> That makes sense, I'll create a separate RFE for that > > Ideal output for `VectorReinterpret` seems to follow a similar pattern to `LoadVector`...etc with regards to the vector size. So seems like a similar solution could be implemented: > > > 1306 VectorReinterpret === _ 1307 [[ 1286 ]] #vectory !orig=1179,979,[846],[738],[646],[145] !jvms: TestCompatibleUseDefTypeSize::test7 @ bci:13 (line 427) Very nice. That would be a good follow-up RFE. Do you want to work on that one? Otherwise you could tag it as a `starter` task, and we'll eventually find someone to do it ;) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2313364841 From galder at openjdk.org Mon Sep 1 09:12:45 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 1 Sep 2025 09:12:45 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v5] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <8_JXUPiLQNWEmDTbAnwB1jdYu6mTE3_NbETZkQabPwU=.78227d3e-8312-47da-bb2b-0a84017fc724@github.com> Message-ID: On Mon, 1 Sep 2025 08:57:28 GMT, Galder Zamarre?o wrote: >> test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java line 460: >> >>> 458: @IR(counts = {IRNode.LOAD_VECTOR_L, "> 0", >>> 459: IRNode.STORE_VECTOR, "> 0", >>> 460: IRNode.VECTOR_REINTERPRET, "> 0"}, >> >> Ah, I just saw that `VECTOR_REINTERPRET` is no `vectorNode`, so we don't check the size for it. Would it have a type and size though? >> >> If so, we could consider making it more precise, like all the vector casts. >> Would be a little bit of work, but it would make the rules more precise. >> Could also be a separate RFE. >> >> >> 2458 public static final String VECTOR_REINTERPRET = PREFIX + "VECTOR_REINTERPRET" + POSTFIX; >> 2459 static { >> 2460 beforeMatchingNameRegex(VECTOR_REINTERPRET, "VectorReinterpret"); >> 2461 } >> 2462 >> 2463 public static final String VECTOR_UCAST_B2S = VECTOR_PREFIX + "VECTOR_UCAST_B2S" + POSTFIX; >> 2464 static { >> 2465 vectorNode(VECTOR_UCAST_B2S, "VectorUCastB2X", TYPE_SHORT); >> 2466 } >> >> >> Depending on the dump, it may not be so easy though. Not sure. > > That makes sense, I'll create a separate RFE for that Ideal output for `VectorReinterpret` seems to follow a similar pattern to `LoadVector`...etc with regards to the vector size. So seems like a similar solution could be implemented: 1306 VectorReinterpret === _ 1307 [[ 1286 ]] #vectory !orig=1179,979,[846],[738],[646],[145] !jvms: TestCompatibleUseDefTypeSize::test7 @ bci:13 (line 427) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2313358195 From galder at openjdk.org Mon Sep 1 09:19:51 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 1 Sep 2025 09:19:51 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v5] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <8_JXUPiLQNWEmDTbAnwB1jdYu6mTE3_NbETZkQabPwU=.78227d3e-8312-47da-bb2b-0a84017fc724@github.com> Message-ID: On Mon, 1 Sep 2025 09:10:29 GMT, Emanuel Peter wrote: >> Ideal output for `VectorReinterpret` seems to follow a similar pattern to `LoadVector`...etc with regards to the vector size. So seems like a similar solution could be implemented: >> >> >> 1306 VectorReinterpret === _ 1307 [[ 1286 ]] #vectory !orig=1179,979,[846],[738],[646],[145] !jvms: TestCompatibleUseDefTypeSize::test7 @ bci:13 (line 427) > > Very nice. That would be a good follow-up RFE. Do you want to work on that one? Otherwise you could tag it as a `starter` task, and we'll eventually find someone to do it ;) Yeah I'd like to work on it. Seems like a good one to work in between bigger tasks. I had a question about it though. I noticed that `STORE_VECTOR` is also in a similar situation. Any specific reason to leave that one as is? Or was it just an oversight? If an oversight, a second RFE could be added for that one? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2313379507 From epeter at openjdk.org Mon Sep 1 09:27:45 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 1 Sep 2025 09:27:45 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v5] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <8_JXUPiLQNWEmDTbAnwB1jdYu6mTE3_NbETZkQabPwU=.78227d3e-8312-47da-bb2b-0a84017fc724@github.com> Message-ID: On Mon, 1 Sep 2025 09:16:39 GMT, Galder Zamarre?o wrote: >> Very nice. That would be a good follow-up RFE. Do you want to work on that one? Otherwise you could tag it as a `starter` task, and we'll eventually find someone to do it ;) > > Yeah I'd like to work on it. Seems like a good one to work in between bigger tasks. > > I had a question about it though. I noticed that `STORE_VECTOR` is also in a similar situation. Any specific reason to leave that one as is? Or was it just an oversight? If an oversight, a second RFE could be added for that one? It would probably also be good if we did stores as well, yes. But you'll touch many many tests, having to specify the type of the store. Still I would say it is worth it ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2313398780 From galder at openjdk.org Mon Sep 1 09:46:46 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 1 Sep 2025 09:46:46 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v5] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> <8_JXUPiLQNWEmDTbAnwB1jdYu6mTE3_NbETZkQabPwU=.78227d3e-8312-47da-bb2b-0a84017fc724@github.com> Message-ID: On Mon, 1 Sep 2025 09:24:45 GMT, Emanuel Peter wrote: >> Yeah I'd like to work on it. Seems like a good one to work in between bigger tasks. >> >> I had a question about it though. I noticed that `STORE_VECTOR` is also in a similar situation. Any specific reason to leave that one as is? Or was it just an oversight? If an oversight, a second RFE could be added for that one? > > It would probably also be good if we did stores as well, yes. But you'll touch many many tests, having to specify the type of the store. Still I would say it is worth it ? I've created [JDK-8366531](https://bugs.openjdk.org/browse/JDK-8366531) for `VectorReinterpret` and [JDK-8366532](https://bugs.openjdk.org/browse/JDK-8366532) for `StoreVector`. I've assigned `VectorReinterpret` one to myself and I left the other one unassigned for someone else to maybe pick it in the future? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26457#discussion_r2313446621 From amitkumar at openjdk.org Mon Sep 1 10:10:42 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 1 Sep 2025 10:10:42 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 07:53:24 GMT, Jaikiran Pai wrote: > Hello Amit, would it be possible to add a jtreg test for this? Do you know what was the code path or values for the `allocateNativeSegment()` call which triggered this issue. Having that replicated in a regression test I think would prevent this from happening again. Hi @jaikiran , I will spend some time over it, current jtreg tests are unable to detect it. This is information Aditi gave me regarding the failure in OpenJ9: `In openj9 the write is happening but it is corrupting the header bytes added by OMR. And the failure is thrown by OMR when it validates the memory segment.` ------------- PR Comment: https://git.openjdk.org/jdk/pull/27027#issuecomment-3241736217 From jpai at openjdk.org Mon Sep 1 10:19:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Sep 2025 10:19:41 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 05:31:43 GMT, Amit Kumar wrote: > Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 > > These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): > > java/foreign/TestFill.java > java/foreign/TestSegments.java > java/foreign/TestSegmentBulkOperationsContentHash.java > java/foreign/TestStringEncoding.java > java/foreign/TestVarArgs.java > > > > ```java > // Always allocate at least some memory so that zero-length segments have distinct > // non-zero addresses. > alignedSize = Math.max(1, alignedSize); > > > Here minimum-allocated size will be 1, which is incorrect because > > > private static void initNativeMemory(long address, long byteSize) { > for (long i = 0; i < byteSize; i += Long.BYTES) { > UNSAFE.putLongUnaligned(null, address + i, 0); > } > } > > `initNativeMemory()` is going to write Long. I think it's OK (and understandable) if the jtreg test doesn't reproduce a JVM crash itself. What would be good, is to have the same API call(s) with those relevant values being invoked from the jtreg test. It may be that we already have a jtreg test which exercises those values and if we are able to identify such an existing test then it would be good to mention it here or in the JBS issue and we won't have to introduce a new one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27027#issuecomment-3241778603 From jpai at openjdk.org Mon Sep 1 10:43:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Sep 2025 10:43:43 GMT Subject: RFR: 8362893: Improve performance for MemorySegment::getString [v2] In-Reply-To: References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com> Message-ID: <13yZjt8iJBOQIYlx22azj4hbKYiRe8RtWi3E_OlypUk=.ce659f47-0ea6-4c9b-a113-0ccb84a636ad@github.com> On Mon, 28 Jul 2025 17:10:13 GMT, Philippe Marschall wrote: >> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor. >> >> Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me. >> >> I ran the tier1 test suite and it passes. >> >> For performance analysis I ran. >> >> make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc" >> >> on an AMD Ryzen 7 PRO 5750GE. >> >> These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation. >> >> >> Benchmark (size) Mode Cnt Score Error Units >> >> ToJavaStringTest.panama_readString 5 avgt 30 18.996 ? 0.044 ns/op >> ToJavaStringTest.panama_readString 5 avgt 30 13.851 ? 0.028 ns/op >> >> ToJavaStringTest.panama_readString 20 avgt 30 23.570 ? 0.050 ns/op >> ToJavaStringTest.panama_readString 20 avgt 30 18.401 ? 0.069 ns/op >> >> ToJavaStringTest.panama_readString 100 avgt 30 32.094 ? 0.207 ns/op >> ToJavaStringTest.panama_readString 100 avgt 30 24.427 ? 0.112 ns/op >> >> ToJavaStringTest.panama_readString 200 avgt 30 43.029 ? 0.185 ns/op >> ToJavaStringTest.panama_readString 200 avgt 30 31.914 ? 0.064 ns/op >> >> ToJavaStringTest.panama_readString 451 avgt 30 81.145 ? 0.403 ns/op >> ToJavaStringTest.panama_readString 451 avgt 30 58.975 ? 0.233 ns/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 72.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 48.000 ? 0.001 B/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 104.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 64.000 ? 0.001 B/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 264.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 144.000 ? 0.0... > > Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year Hello Philippe, > [3fe0d29](https://github.com/openjdk/jdk/commit/3fe0d29ec3b5b327d633726677ba1809eec27665) should fix the issue, should I merge master first to the branch? It's OK to merge against latest master and update this PR. The skara bots have been enhanced some time back to not force a re-review if the change is merely a clean merge. I'll also run tier testing in our CI with this PR to make sure nothing breaks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26493#issuecomment-3241881784 From rgiulietti at openjdk.org Mon Sep 1 13:08:53 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 1 Sep 2025 13:08:53 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 19:00:23 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Revision changes Is there some documentation proving your claims in the CSR about the accuracy (1.1 ulp and 0.55 ulp, resp.)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3242300097 From duke at openjdk.org Mon Sep 1 13:11:53 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 1 Sep 2025 13:11:53 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:05:50 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Revision changes > > Is there some documentation proving your claims in the CSR about the accuracy (1.1 ulp and 0.55 ulp, resp.)? @rgiulietti The code of my implementation provides it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3242314747 From lkorinth at openjdk.org Mon Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From tschatzl at openjdk.org Mon Sep 1 13:24:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 13:24:37 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v51] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * remove unused G1DetachedRefinementStats_lock - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 58 more: https://git.openjdk.org/jdk/compare/98af1892...4a41b40b ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=50 Stats: 7100 lines in 112 files changed: 2584 ins; 3578 del; 938 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From tschatzl at openjdk.org Mon Sep 1 14:24:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 14:24:34 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v52] In-Reply-To: References: Message-ID: <8ppqEuxHuhM5tXXssVXaq-uQlixvWerkx3UxT-XYTmg=.b6a5ee73-33f0-4f58-b14d-808895da6347@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * commit merge changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/4a41b40b..b3873d66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=50-51 Stats: 11 lines in 2 files changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31: > >> 29: * @compile SuspendResume2.java >> 30: * @run driver jdk.test.lib.FileInstaller . . >> 31: * @run main/othervm/native/timeout=700 > > Why `700` instead of `480` in this file? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). > >> while not multiplying a 10x factor with four resulting in a 40x factor. > > Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From vyazici at openjdk.org Mon Sep 1 16:16:23 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 1 Sep 2025 16:16:23 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v11] In-Reply-To: References: Message-ID: > `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Fix `ClassCastException` spotted by `ReadWriteString` - Merge remote-tracking branch 'upstream/master' into jlaNoRepl - Improve Javadoc of touched `encode*()` methods - Rename `exceptionClass` to `exClass` - Rename `NoReplacement` suffix to `OrThrow` - Simplify `encodeWithEncoder` and trim long lines - Improve docs - Improve "sneaky throws" - Improve comment style - Renamed to `malformedASCII` - ... and 17 more: https://git.openjdk.org/jdk/compare/7f0cd648...a69f9fd3 ------------- Changes: https://git.openjdk.org/jdk/pull/26413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=10 Stats: 462 lines in 8 files changed: 242 ins; 122 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/26413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413 PR: https://git.openjdk.org/jdk/pull/26413 From jvernee at openjdk.org Mon Sep 1 17:00:41 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 1 Sep 2025 17:00:41 GMT Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build In-Reply-To: References: Message-ID: <2REfnawHIfGgnFBrEQMb2vDBkUjLNnzbFRV726KSOJ0=.c7a05f23-3268-4261-8a8a-a503824a8fc0@github.com> On Fri, 29 Aug 2025 19:13:27 GMT, Chen Liang wrote: > Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class. > > This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too. > > Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData. > >
> > Diff from new to old (backwards): > > > > liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > index 13ef65b..49408a2 100644 > --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java > +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer; > import jdk.internal.vm.annotation.ForceInline; > import jdk.internal.vm.annotation.Hidden; > > -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator. > -// Do not edit! > +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit. > @AOTSafeClassInitializer > final class VarHandleGuards { > > > >
> > Testing: java/lang/invoke. @PaulSandoz Do you know if there was/is a particular reason for not generating the VarHandle guards as part of the build? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27009#issuecomment-3242929547 From vyazici at openjdk.org Mon Sep 1 19:08:44 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 1 Sep 2025 19:08:44 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v4] In-Reply-To: <46MfOJA8bICEbZ7EpwzTealkJKqvsxREIKZhsyA-LRE=.295d951f-1eb7-4ad7-9e6a-3f2810c581ce@github.com> References: <46MfOJA8bICEbZ7EpwzTealkJKqvsxREIKZhsyA-LRE=.295d951f-1eb7-4ad7-9e6a-3f2810c581ce@github.com> Message-ID: On Tue, 19 Aug 2025 14:59:04 GMT, Roger Riggs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant type parameters > > It seems that the API is overloaded trying to satisfy too many requirements, replace/noreplace, throw/nothrow and supporting arbitrary Charsets. There are multiple callers that only need to create a string from byte array holding latin1. > They are burdened with catching and ignoring exceptions that do not occur. > > I'm suggesting breaking out that use case in PR#https://github.com/openjdk/jdk/pull/26831. > That leaves `Files.readString` that needs the full CharSet/noReplace/throw behavior. @RogerRiggs, @liach, @AlanBateman, I needed to push a `ClassCastException` fix in a69f9fd, which further simplified the sneaky-throws logic in `String`. Would one of you mind, unless you have objections, re-approving the PR, please? Note that I've attached passing `tier1,2` results to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3243114718 From duke at openjdk.org Mon Sep 1 19:22:50 2025 From: duke at openjdk.org (Philippe Marschall) Date: Mon, 1 Sep 2025 19:22:50 GMT Subject: RFR: 8362893: Improve performance for MemorySegment::getString [v3] In-Reply-To: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com> References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com> Message-ID: > Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor. > > Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me. > > I ran the tier1 test suite and it passes. > > For performance analysis I ran. > > make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc" > > on an AMD Ryzen 7 PRO 5750GE. > > These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation. > > > Benchmark (size) Mode Cnt Score Error Units > > ToJavaStringTest.panama_readString 5 avgt 30 18.996 ? 0.044 ns/op > ToJavaStringTest.panama_readString 5 avgt 30 13.851 ? 0.028 ns/op > > ToJavaStringTest.panama_readString 20 avgt 30 23.570 ? 0.050 ns/op > ToJavaStringTest.panama_readString 20 avgt 30 18.401 ? 0.069 ns/op > > ToJavaStringTest.panama_readString 100 avgt 30 32.094 ? 0.207 ns/op > ToJavaStringTest.panama_readString 100 avgt 30 24.427 ? 0.112 ns/op > > ToJavaStringTest.panama_readString 200 avgt 30 43.029 ? 0.185 ns/op > ToJavaStringTest.panama_readString 200 avgt 30 31.914 ? 0.064 ns/op > > ToJavaStringTest.panama_readString 451 avgt 30 81.145 ? 0.403 ns/op > ToJavaStringTest.panama_readString 451 avgt 30 58.975 ? 0.233 ns/op > > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 72.000 ? 0.001 B/op > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 48.000 ? 0.001 B/op > > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 104.000 ? 0.001 B/op > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 64.000 ? 0.001 B/op > > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 264.000 ? 0.001 B/op > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 144.000 ? 0.001 B/op > > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 200 avgt ... Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8362893 - Fix copyright year - 8362893: Improve performance for MemorySegment::getString Use JavaLangAccess::uncheckedNewStringNoRepl in MemorySegment::getString to avoid byte[] allocation in String constructor. Fall back to the old code in the case of malformed input to get replacement characters. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26493/files - new: https://git.openjdk.org/jdk/pull/26493/files/130ad859..3a70b7fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26493&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26493&range=01-02 Stats: 63769 lines in 1701 files changed: 40575 ins; 16316 del; 6878 mod Patch: https://git.openjdk.org/jdk/pull/26493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26493/head:pull/26493 PR: https://git.openjdk.org/jdk/pull/26493 From jpai at openjdk.org Tue Sep 2 01:32:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 01:32:54 GMT Subject: RFR: 8362893: Improve performance for MemorySegment::getString [v3] In-Reply-To: References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com> Message-ID: On Mon, 1 Sep 2025 19:22:50 GMT, Philippe Marschall wrote: >> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor. >> >> Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me. >> >> I ran the tier1 test suite and it passes. >> >> For performance analysis I ran. >> >> make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc" >> >> on an AMD Ryzen 7 PRO 5750GE. >> >> These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation. >> >> >> Benchmark (size) Mode Cnt Score Error Units >> >> ToJavaStringTest.panama_readString 5 avgt 30 18.996 ? 0.044 ns/op >> ToJavaStringTest.panama_readString 5 avgt 30 13.851 ? 0.028 ns/op >> >> ToJavaStringTest.panama_readString 20 avgt 30 23.570 ? 0.050 ns/op >> ToJavaStringTest.panama_readString 20 avgt 30 18.401 ? 0.069 ns/op >> >> ToJavaStringTest.panama_readString 100 avgt 30 32.094 ? 0.207 ns/op >> ToJavaStringTest.panama_readString 100 avgt 30 24.427 ? 0.112 ns/op >> >> ToJavaStringTest.panama_readString 200 avgt 30 43.029 ? 0.185 ns/op >> ToJavaStringTest.panama_readString 200 avgt 30 31.914 ? 0.064 ns/op >> >> ToJavaStringTest.panama_readString 451 avgt 30 81.145 ? 0.403 ns/op >> ToJavaStringTest.panama_readString 451 avgt 30 58.975 ? 0.233 ns/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 72.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 48.000 ? 0.001 B/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 104.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 64.000 ? 0.001 B/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 264.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 144.000 ? 0.0... > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8362893 > - Fix copyright year > - 8362893: Improve performance for MemorySegment::getString > > Use JavaLangAccess::uncheckedNewStringNoRepl in MemorySegment::getString > to avoid byte[] allocation in String constructor. > > Fall back to the old code in the case of malformed input to get > replacement characters. tier testing in our CI came back fine for tier1, tier2, tier3. Per and Maurizio have approved this PR and there's been no change (except a clean merge) since then. Once you issue an "/integrate" again, I'll go ahead and sponsor it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26493#issuecomment-3243518359 From jpai at openjdk.org Tue Sep 2 05:05:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 05:05:41 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 05:31:43 GMT, Amit Kumar wrote: > Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 > > These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): > > java/foreign/TestFill.java > java/foreign/TestSegments.java > java/foreign/TestSegmentBulkOperationsContentHash.java > java/foreign/TestStringEncoding.java > java/foreign/TestVarArgs.java > > > > ```java > // Always allocate at least some memory so that zero-length segments have distinct > // non-zero addresses. > alignedSize = Math.max(1, alignedSize); > > > Here minimum-allocated size will be 1, which is incorrect because > > > private static void initNativeMemory(long address, long byteSize) { > for (long i = 0; i < byteSize; i += Long.BYTES) { > UNSAFE.putLongUnaligned(null, address + i, 0); > } > } > > `initNativeMemory()` is going to write Long. I had a deeper look at this and this specific issue can happen only when the `byteSize` is 0 for example when calling Arena.allocate(). The `testZeroLengthNativeSegment()` test method in `test/jdk/java/foreign/TestSegments.java` already covers this code path and exercises this bug. So I think it's fine if you don't add any additional test as part of this PR. I just have one more review comment which I'll add inline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27027#issuecomment-3243788621 From jpai at openjdk.org Tue Sep 2 05:18:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 05:18:41 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 05:31:43 GMT, Amit Kumar wrote: > Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 > > These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): > > java/foreign/TestFill.java > java/foreign/TestSegments.java > java/foreign/TestSegmentBulkOperationsContentHash.java > java/foreign/TestStringEncoding.java > java/foreign/TestVarArgs.java > > > > ```java > // Always allocate at least some memory so that zero-length segments have distinct > // non-zero addresses. > alignedSize = Math.max(1, alignedSize); > > > Here minimum-allocated size will be 1, which is incorrect because > > > private static void initNativeMemory(long address, long byteSize) { > for (long i = 0; i < byteSize; i += Long.BYTES) { > UNSAFE.putLongUnaligned(null, address + i, 0); > } > } > > `initNativeMemory()` is going to write Long. src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 201: > 199: // Always allocate at least some memory so that zero-length segments have distinct > 200: // non-zero addresses. > 201: alignedSize = Math.max(Long.BYTES, alignedSize); A few lines above this code there's a comment which says: // Align the allocation size up to a multiple of 8 so we can init the memory with longs long alignedSize = init ? Utils.alignUp(byteSize, Long.BYTES) : byteSize; Should we have a similar comment as well as a check for `init` here? After all, we are increasing this size here because of `init` initializing the allocated memory. So perhaps something like: // Always allocate at least some memory so that zero-length segments have distinct // non-zero addresses. If we are initializing the allocated memory, then use a minimum // size of 8 because we init the memory with longs. alignedSize = Math.max((init ? Long.BYTES : 1), alignedSize); If you do use this newer proposed change, then please have it verified against the original reproducer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27027#discussion_r2314932199 From amitkumar at openjdk.org Tue Sep 2 05:40:46 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 2 Sep 2025 05:40:46 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: References: Message-ID: <-ESB6L5qPNFbDUwQukYMb4xMd6H3DtKOUbIa9NSrWnM=.c39f22f5-a92f-417a-93a6-318977ae4238@github.com> On Tue, 2 Sep 2025 05:02:47 GMT, Jaikiran Pai wrote: >The testZeroLengthNativeSegment() test method in test/jdk/java/foreign/TestSegments.java already covers this code path and exercises this bug. Hi @jaikiran , I tried to spend sometime over it as current tests were passing, but couldn't reproduce the failure on openjdk. I guess, we will just pass it for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27027#issuecomment-3243846300 From jpai at openjdk.org Tue Sep 2 05:46:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 05:46:42 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: <-ESB6L5qPNFbDUwQukYMb4xMd6H3DtKOUbIa9NSrWnM=.c39f22f5-a92f-417a-93a6-318977ae4238@github.com> References: <-ESB6L5qPNFbDUwQukYMb4xMd6H3DtKOUbIa9NSrWnM=.c39f22f5-a92f-417a-93a6-318977ae4238@github.com> Message-ID: On Tue, 2 Sep 2025 05:38:22 GMT, Amit Kumar wrote: > but couldn't reproduce the failure on openjdk. Not being able to generate a JVM crash or a test failure from that test is understandable and OK. Such memory access issues aren't always reproducible in a deterministic manner. So yes, it's OK to not introduce a new test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27027#issuecomment-3243855467 From duke at openjdk.org Tue Sep 2 05:51:46 2025 From: duke at openjdk.org (Philippe Marschall) Date: Tue, 2 Sep 2025 05:51:46 GMT Subject: Integrated: 8362893: Improve performance for MemorySegment::getString In-Reply-To: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com> References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com> Message-ID: <3kT6MyxOhG6EA8c2PA6ush1W0p_VlKrylGQk4_ITi0c=.54a6b5ff-54c5-4f00-a4fc-c6fa8f030729@github.com> On Sun, 27 Jul 2025 12:36:20 GMT, Philippe Marschall wrote: > Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor. > > Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me. > > I ran the tier1 test suite and it passes. > > For performance analysis I ran. > > make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc" > > on an AMD Ryzen 7 PRO 5750GE. > > These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation. > > > Benchmark (size) Mode Cnt Score Error Units > > ToJavaStringTest.panama_readString 5 avgt 30 18.996 ? 0.044 ns/op > ToJavaStringTest.panama_readString 5 avgt 30 13.851 ? 0.028 ns/op > > ToJavaStringTest.panama_readString 20 avgt 30 23.570 ? 0.050 ns/op > ToJavaStringTest.panama_readString 20 avgt 30 18.401 ? 0.069 ns/op > > ToJavaStringTest.panama_readString 100 avgt 30 32.094 ? 0.207 ns/op > ToJavaStringTest.panama_readString 100 avgt 30 24.427 ? 0.112 ns/op > > ToJavaStringTest.panama_readString 200 avgt 30 43.029 ? 0.185 ns/op > ToJavaStringTest.panama_readString 200 avgt 30 31.914 ? 0.064 ns/op > > ToJavaStringTest.panama_readString 451 avgt 30 81.145 ? 0.403 ns/op > ToJavaStringTest.panama_readString 451 avgt 30 58.975 ? 0.233 ns/op > > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 72.000 ? 0.001 B/op > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 48.000 ? 0.001 B/op > > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 104.000 ? 0.001 B/op > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 64.000 ? 0.001 B/op > > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 264.000 ? 0.001 B/op > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 144.000 ? 0.001 B/op > > ToJavaStringTest.panama_readString:gc.alloc.rate.norm 200 avgt ... This pull request has now been integrated. Changeset: 8f11d83a Author: Philippe Marschall Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/8f11d83a0126f8179d72e714595588b631e6451d Stats: 20 lines in 1 file changed: 16 ins; 0 del; 4 mod 8362893: Improve performance for MemorySegment::getString Reviewed-by: pminborg, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/26493 From jpai at openjdk.org Tue Sep 2 06:15:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 06:15:41 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently In-Reply-To: References: Message-ID: On Mon, 18 Aug 2025 08:01:58 GMT, Johny Jose wrote: > Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 There's some discussion going on in the linked JBS issue about this test failure which suggests that this proposed change isn't going to address the intermittent failures. This test has been problem listed for now through https://bugs.openjdk.org/browse/JDK-8366131 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26815#issuecomment-3243919749 From pminborg at openjdk.org Tue Sep 2 07:15:50 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 2 Sep 2025 07:15:50 GMT Subject: RFR: 8362893: Improve performance for MemorySegment::getString [v3] In-Reply-To: References: <2Ylzaqh6EGpyeUXRRXrrDizXVqCghqobGmDHYEiTy0A=.078ad8e4-9eca-4ab6-86cd-60bf8b894201@github.com> Message-ID: On Mon, 1 Sep 2025 19:22:50 GMT, Philippe Marschall wrote: >> Use `JavaLangAccess::uncheckedNewStringNoRepl` in `MemorySegment::getString` to avoid byte[] allocation in the String constructor. >> >> Fall back to the old code in the case of malformed input to get replacement characters as per Javadoc API specification. The existing tests in `TestStringEncoding` seem sufficient to me. >> >> I ran the tier1 test suite and it passes. >> >> For performance analysis I ran. >> >> make test TEST="micro:org.openjdk.bench.java.lang.foreign.ToJavaStringTest" MICRO="OPTIONS=-prof gc" >> >> on an AMD Ryzen 7 PRO 5750GE. >> >> These are the formatted results, the current master is the line on top, this feature branch is the line below. We can see an improvement in throughput driven by a reduction in allocation. >> >> >> Benchmark (size) Mode Cnt Score Error Units >> >> ToJavaStringTest.panama_readString 5 avgt 30 18.996 ? 0.044 ns/op >> ToJavaStringTest.panama_readString 5 avgt 30 13.851 ? 0.028 ns/op >> >> ToJavaStringTest.panama_readString 20 avgt 30 23.570 ? 0.050 ns/op >> ToJavaStringTest.panama_readString 20 avgt 30 18.401 ? 0.069 ns/op >> >> ToJavaStringTest.panama_readString 100 avgt 30 32.094 ? 0.207 ns/op >> ToJavaStringTest.panama_readString 100 avgt 30 24.427 ? 0.112 ns/op >> >> ToJavaStringTest.panama_readString 200 avgt 30 43.029 ? 0.185 ns/op >> ToJavaStringTest.panama_readString 200 avgt 30 31.914 ? 0.064 ns/op >> >> ToJavaStringTest.panama_readString 451 avgt 30 81.145 ? 0.403 ns/op >> ToJavaStringTest.panama_readString 451 avgt 30 58.975 ? 0.233 ns/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 72.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 5 avgt 30 48.000 ? 0.001 B/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 104.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 20 avgt 30 64.000 ? 0.001 B/op >> >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 264.000 ? 0.001 B/op >> ToJavaStringTest.panama_readString:gc.alloc.rate.norm 100 avgt 30 144.000 ? 0.0... > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8362893 > - Fix copyright year > - 8362893: Improve performance for MemorySegment::getString > > Use JavaLangAccess::uncheckedNewStringNoRepl in MemorySegment::getString > to avoid byte[] allocation in String constructor. > > Fall back to the old code in the case of malformed input to get > replacement characters. Thanks, Philippe, for fixing this issue, and thanks to the reviewers. This is a welcome performance improvement. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26493#issuecomment-3244075061 From pminborg at openjdk.org Tue Sep 2 07:21:50 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 2 Sep 2025 07:21:50 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <22V1rYuOtYARMeEUsFkV-SR6ezs4tfvj6K-XE_Lg-qA=.dd66d148-f759-47f3-8e86-f9c45cd43a20@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> <22V1rYuOtYARMeEUsFkV-SR6ezs4tfvj6K-XE_Lg-qA=.dd66d148-f759-47f3-8e86-f9c45cd43a20@github.com> Message-ID: <2lk-MLbIZMKEXquuPPL7mgM4jRjY2rPYdLqP54pTRmE=.ff585c6c-7422-46b6-bc77-c0a2af111301@github.com> On Thu, 28 Aug 2025 15:02:57 GMT, Darragh Clarke wrote: >> Darragh Clarke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: >> >> - fixed copyright header >> - merged master into branch >> - moved repeating code into own method >> - implementing feedback, adding missing errno checks, cleanup >> - feedback >> - general cleanup >> - small refactoring >> - Performance >> - implementing feedback >> - removed unrelated change >> - ... and 2 more: https://git.openjdk.org/jdk/compare/e5469821...cc5f558a > > Thanks for the thorough review, I'll address all these in the next commit. > As for the changes to generated code, I'll draft up a list of what changed and why, though FFMUtils in particular came about as trying to move reusable utility methods into a shared place to cut down on code duplication going forward > @DarraghClarke @minborg Would it be possible to provide a brief summary on what modifications have been done to the jextract-generated classes? The use of FFMUtils jumps out. Ideally they would be checked in without modification as it makes it easy to re-generate. It might be that this never happens but there is something a bit uncomfortable about checking in modified sources. I think we could document the changes where we document how jextract is run. Ideally, we spoke about `sed` but maybe a more informal description can be made? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3244089693 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From alanb at openjdk.org Tue Sep 2 07:38:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Sep 2025 07:38:44 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <2lk-MLbIZMKEXquuPPL7mgM4jRjY2rPYdLqP54pTRmE=.ff585c6c-7422-46b6-bc77-c0a2af111301@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> <22V1rYuOtYARMeEUsFkV-SR6ezs4tfvj6K-XE_Lg-qA=.dd66d148-f759-47f3-8e86-f9c45cd43a20@github.com> <2lk-MLbIZMKEXquuPPL7mgM4jRjY2rPYdLqP54pTRmE=.ff585c6c-7422-46b6-bc77-c0a2af111301@github.com> Message-ID: On Tue, 2 Sep 2025 07:18:54 GMT, Per Minborg wrote: > I think we could document the changes where we document how jextract is run. Ideally, we spoke about `sed` but maybe a more informal description can be made? That might be okay. In the distant past the in-tree copy of the zlib code needed a few patches. The list of changes, and reasoning, went into a readme file to help future sync ups. It should be very rare that we need to re-run jextract but if we do then it's important to document the patches. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3244146703 From stefank at openjdk.org Tue Sep 2 08:03:27 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 2 Sep 2025 08:03:27 GMT Subject: RFR: 8366298: FDLeakTest sometimes takes minutes to complete on Linux [v3] In-Reply-To: References: Message-ID: > While investigating [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on Linux. > > The reason is that the test performs a `fcntl` call for each and every potential file descriptor number. This can be a large number of calls and sometimes results in minutes-long test executions. > > I propose that we fix this by limiting the max number of open file descriptors. This lowers the test execution time to about 1 second. > > The test has two processes. One that executes the libFDLeaker.c code below as an agent in the test JVM, then it forks into a exeFDLeakTester.c, which reads the property `int max_fd = (int)sysconf(_SC_OPEN_MAX);`. The setting of `RLIMIT_NOFILE` to `100` lowers `max_fd` to `100`. I've verified this on both Linux and on macOS. > > I've run the test manually on Linux and macOS and verified that it runs faster. I've also run this through tier1. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Remove jtreg timeouts - Merge remote-tracking branch 'upstream/master' into 8366298_fdleaktest - Add error logging - 8366298: FDLeakTest sometimes takes minutes to complete on Linux ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26979/files - new: https://git.openjdk.org/jdk/pull/26979/files/78fbf6d7..382647c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26979&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26979&range=01-02 Stats: 12952 lines in 682 files changed: 9828 ins; 855 del; 2269 mod Patch: https://git.openjdk.org/jdk/pull/26979.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26979/head:pull/26979 PR: https://git.openjdk.org/jdk/pull/26979 From duke at openjdk.org Tue Sep 2 09:27:52 2025 From: duke at openjdk.org (Vanitha B P) Date: Tue, 2 Sep 2025 09:27:52 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected Message-ID: Problem Statements: 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. 2. ZoneID was not displaying in the window as it is displaying in the lower releases. Test Results: jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java Passed: java/util/TimeZone/DefaultTimeZoneTest.java Test results: passed: 1 ------------- Commit messages: - 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected Changes: https://git.openjdk.org/jdk/pull/27043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366537 Stats: 30 lines in 1 file changed: 26 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From amitkumar at openjdk.org Tue Sep 2 09:43:23 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 2 Sep 2025 09:43:23 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() [v2] In-Reply-To: References: Message-ID: > Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 > > These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): > > java/foreign/TestFill.java > java/foreign/TestSegments.java > java/foreign/TestSegmentBulkOperationsContentHash.java > java/foreign/TestStringEncoding.java > java/foreign/TestVarArgs.java > > > > ```java > // Always allocate at least some memory so that zero-length segments have distinct > // non-zero addresses. > alignedSize = Math.max(1, alignedSize); > > > Here minimum-allocated size will be 1, which is incorrect because > > > private static void initNativeMemory(long address, long byteSize) { > for (long i = 0; i < byteSize; i += Long.BYTES) { > UNSAFE.putLongUnaligned(null, address + i, 0); > } > } > > `initNativeMemory()` is going to write Long. Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27027/files - new: https://git.openjdk.org/jdk/pull/27027/files/8bbef849..18c67d55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27027&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27027&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27027/head:pull/27027 PR: https://git.openjdk.org/jdk/pull/27027 From duke at openjdk.org Tue Sep 2 10:50:33 2025 From: duke at openjdk.org (Vanitha B P) Date: Tue, 2 Sep 2025 10:50:33 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v2] In-Reply-To: References: Message-ID: <2LPtj3TfEBNxn52lApbp5klrVVW2DZ-bG2nApVAgEoY=.711dc754-ef17-4139-a3b3-cb5666b71324@github.com> > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: modified tzid variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27043/files - new: https://git.openjdk.org/jdk/pull/27043/files/303709d8..7a2a87d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From alanb at openjdk.org Tue Sep 2 11:43:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Sep 2025 11:43:48 GMT Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods [v11] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 16:16:23 GMT, Volkan Yazici wrote: >> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. > > Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Fix `ClassCastException` spotted by `ReadWriteString` > - Merge remote-tracking branch 'upstream/master' into jlaNoRepl > - Improve Javadoc of touched `encode*()` methods > - Rename `exceptionClass` to `exClass` > - Rename `NoReplacement` suffix to `OrThrow` > - Simplify `encodeWithEncoder` and trim long lines > - Improve docs > - Improve "sneaky throws" > - Improve comment style > - Renamed to `malformedASCII` > - ... and 17 more: https://git.openjdk.org/jdk/compare/7f0cd648...a69f9fd3 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3176161682 From eirbjo at gmail.com Tue Sep 2 11:46:04 2025 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 2 Sep 2025 13:46:04 +0200 Subject: Q: List.of(E... elements) specification with regards to underlying array updates Message-ID: Hi, In Venkat's JavaOne 2025 "Know your Java" talk [0], he shows how Arrays.asList [1] returns a fixed-size List backed by the given array. Updates to the List are visible to the underlying array and updates to the array are visible to the List. This mix of fixed-size but update-friendliness seems clearly documented in the API, but is perhaps not super intuitive. Venkat then recommends using List.of(E... elements) [2] instead, since this returns an unmodifiable List. However, while the List returned by List.of is specified to be unmodifiable, neither the method specification nor the linked "Unmodifiable lists" section [3] seems to clearly specify whether updates to the underlying array are visible in the returned list. One could argue that the word "unmodifiable" implies that updates to the underlying array are in fact invisible to the List. However, the way the specification talks about "unmodifiable lists", I also think a passable interpretation could be that this is a property of actions performed on the List implementation, not on the array. Interestingly, List.copyOf [4] explicitly specifies that modifications to the given Collection are not reflected in the returned List. (Even when this may be inferred from the method name!). This prose is what I feel may be missing from List.of(E... elements). Should this aspect be clarified, am I missing something in the existing specification, or should people be expected to not be difficult like me and instead just read between the lines and infer this property? Cheers, Eirik. [0] https://www.youtube.com/watch?v=v5Q7TC5u5Co [1] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/Arrays.html#asList(T...) [2] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/List.html#of(E...) [3] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/List.html#unmodifiable [4] https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/List.html#copyOf(java.util.Collection) From eirbjo at gmail.com Tue Sep 2 12:00:56 2025 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 2 Sep 2025 14:00:56 +0200 Subject: Q: List.of(E... elements) specification with regards to underlying array updates In-Reply-To: References: Message-ID: On Tue, Sep 2, 2025 at 1:46?PM Eirik Bj?rsn?s wrote: > Interestingly, List.copyOf [4] explicitly specifies that modifications > to the given Collection are not reflected in the returned List. (Even > when this may be inferred from the method name!). This prose is what I > feel may be missing from List.of(E... elements). TLDR: I think my long-winded question boils down to: Should we add something like the following to List.of(E... elements): * If the given array is subsequently modified, the returned List will not * reflect such modifications. This would clarify this aspect and provide parity with List.copyOf. Eirik. From vyazici at openjdk.org Tue Sep 2 12:46:02 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 12:46:02 GMT Subject: Integrated: 8356439: Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici wrote: > `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR replaces the `NoRepl` suffix with `NoReplacement` in method names and consistently uses `throws CCE` in method footprints. This pull request has now been integrated. Changeset: eea50fbc Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/eea50fbc1b24710b18eff4b59dc90dee3736cd95 Stats: 462 lines in 8 files changed: 242 ins; 122 del; 98 mod 8356439: Rename JavaLangAccess::*NoRepl methods Reviewed-by: alanb, liach, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/26413 From vyazici at openjdk.org Tue Sep 2 13:17:03 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 13:17:03 GMT Subject: RFR: 8356439: Backout recent JavaLangAccess changes breaking the build Message-ID: Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. ------------- Commit messages: - Revert "8356439: Rename JavaLangAccess::*NoRepl methods" Changes: https://git.openjdk.org/jdk/pull/27050/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356439 Stats: 462 lines in 8 files changed: 122 ins; 242 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/27050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27050/head:pull/27050 PR: https://git.openjdk.org/jdk/pull/27050 From epeter at openjdk.org Tue Sep 2 13:23:49 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 2 Sep 2025 13:23:49 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v6] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: On Mon, 1 Sep 2025 09:03:24 GMT, Galder Zamarre?o wrote: >> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations. >> >> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows: >> >> >> Benchmark (seed) (size) Mode Cnt Base Patch Units Diff >> VectorBitConversion.doubleToLongBits 0 2048 thrpt 8 1168.782 1157.717 ops/ms -1% >> VectorBitConversion.doubleToRawLongBits 0 2048 thrpt 8 3999.387 7353.936 ops/ms +83% >> VectorBitConversion.floatToIntBits 0 2048 thrpt 8 1200.338 1188.206 ops/ms -1% >> VectorBitConversion.floatToRawIntBits 0 2048 thrpt 8 4058.248 14792.474 ops/ms +264% >> VectorBitConversion.intBitsToFloat 0 2048 thrpt 8 3050.313 14984.246 ops/ms +391% >> VectorBitConversion.longBitsToDouble 0 2048 thrpt 8 3022.691 7379.360 ops/ms +144% >> >> >> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control. >> >> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions. > > Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: > > Adjust vector size expectations Testing passed, Approved! @galderz Thanks for working on this :) ------------- PR Review: https://git.openjdk.org/jdk/pull/26457#pullrequestreview-3176546977 From lkorinth at openjdk.org Tue Sep 2 13:25:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 13:25:47 GMT Subject: RFR: 8366298: FDLeakTest sometimes takes minutes to complete on Linux [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 08:03:27 GMT, Stefan Karlsson wrote: >> While investigating [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on Linux. >> >> The reason is that the test performs a `fcntl` call for each and every potential file descriptor number. This can be a large number of calls and sometimes results in minutes-long test executions. >> >> I propose that we fix this by limiting the max number of open file descriptors. This lowers the test execution time to about 1 second. >> >> The test has two processes. One that executes the libFDLeaker.c code below as an agent in the test JVM, then it forks into a exeFDLeakTester.c, which reads the property `int max_fd = (int)sysconf(_SC_OPEN_MAX);`. The setting of `RLIMIT_NOFILE` to `100` lowers `max_fd` to `100`. I've verified this on both Linux and on macOS. >> >> I've run the test manually on Linux and macOS and verified that it runs faster. I've also run this through tier1. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Remove jtreg timeouts > - Merge remote-tracking branch 'upstream/master' into 8366298_fdleaktest > - Add error logging > - 8366298: FDLeakTest sometimes takes minutes to complete on Linux I have looked through this and it looks good to me. ------------- Marked as reviewed by lkorinth (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26979#pullrequestreview-3176557134 From jpai at openjdk.org Tue Sep 2 13:50:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 13:50:43 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. I've verified that this is a clean "git revert" of the original eea50fbc1b24710b18eff4b59dc90dee3736cd95 commit. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176660366 From serb at openjdk.org Tue Sep 2 14:08:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Sep 2025 14:08:48 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176741003 From alanb at openjdk.org Tue Sep 2 14:11:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Sep 2025 14:11:41 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176750059 From henryjen at openjdk.org Tue Sep 2 14:27:28 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 2 Sep 2025 14:27:28 GMT Subject: RFR: 8359174: tools/jlink/JLink20000Packages.java timed out [v8] In-Reply-To: References: Message-ID: > Create a jar directly from the memory instead of real file, this should reduce the I/O overhead which likely the reason for the time out. > The issue is not reproducible locally, and fails intermittently, so we simply trying to reduce time needed. > The jar file created is verified manually running jtreg with retain=all. Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge openjdk/master - Merge openjdk/master' into JDK-8359174 - Clean up module dependencies - Clean up jtreg directives - Adapt review feedbacks - Update copyright year - Update copyright year - cleanup - 8359174: tools/jlink/JLink20000Packages.java timed out ------------- Changes: https://git.openjdk.org/jdk/pull/25981/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25981&range=07 Stats: 124 lines in 2 files changed: 56 ins; 45 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/25981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25981/head:pull/25981 PR: https://git.openjdk.org/jdk/pull/25981 From syan at openjdk.org Tue Sep 2 14:34:41 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 2 Sep 2025 14:34:41 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176850369 From myankelevich at openjdk.org Tue Sep 2 14:38:44 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 2 Sep 2025 14:38:44 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v2] In-Reply-To: <2LPtj3TfEBNxn52lApbp5klrVVW2DZ-bG2nApVAgEoY=.711dc754-ef17-4139-a3b3-cb5666b71324@github.com> References: <2LPtj3TfEBNxn52lApbp5klrVVW2DZ-bG2nApVAgEoY=.711dc754-ef17-4139-a3b3-cb5666b71324@github.com> Message-ID: On Tue, 2 Sep 2025 10:50:33 GMT, Vanitha B P wrote: >> Problem Statements: >> 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. >> 2. ZoneID was not displaying in the window as it is displaying in the lower releases. >> >> Test Results: >> jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java >> >> Passed: java/util/TimeZone/DefaultTimeZoneTest.java >> Test results: passed: 1 > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > modified tzid variable test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 111: > 109: panel.setLayout(new BoxLayout(panel, BoxLayout.PAGE_AXIS)); > 110: // Time zone ID label > 111: var tzid = new JLabel("Time zone ID: " + SDF.getTimeZone().getID(), SwingConstants.CENTER); minor: do you think changing it to a more intuitive `timeZoneID` would make it easier to read? If you want to leave it as is - I don't mind ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27043#discussion_r2316292304 From epeter at openjdk.org Tue Sep 2 14:56:46 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 2 Sep 2025 14:56:46 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v6] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: On Mon, 1 Sep 2025 09:03:24 GMT, Galder Zamarre?o wrote: >> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations. >> >> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows: >> >> >> Benchmark (seed) (size) Mode Cnt Base Patch Units Diff >> VectorBitConversion.doubleToLongBits 0 2048 thrpt 8 1168.782 1157.717 ops/ms -1% >> VectorBitConversion.doubleToRawLongBits 0 2048 thrpt 8 3999.387 7353.936 ops/ms +83% >> VectorBitConversion.floatToIntBits 0 2048 thrpt 8 1200.338 1188.206 ops/ms -1% >> VectorBitConversion.floatToRawIntBits 0 2048 thrpt 8 4058.248 14792.474 ops/ms +264% >> VectorBitConversion.intBitsToFloat 0 2048 thrpt 8 3050.313 14984.246 ops/ms +391% >> VectorBitConversion.longBitsToDouble 0 2048 thrpt 8 3022.691 7379.360 ops/ms +144% >> >> >> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control. >> >> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions. > > Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: > > Adjust vector size expectations Marked as reviewed by epeter (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26457#pullrequestreview-3176939920 From galder at openjdk.org Tue Sep 2 14:56:47 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Tue, 2 Sep 2025 14:56:47 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v6] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: On Mon, 1 Sep 2025 09:07:07 GMT, Emanuel Peter wrote: >> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust vector size expectations > > Perfect, thanks for the update! I'll submit testing again :) @eme64 thanks for running the tests! Did you actually mark the review as approved? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3245692537 From rriggs at openjdk.org Tue Sep 2 14:58:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 2 Sep 2025 14:58:42 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176950881 From duke at openjdk.org Tue Sep 2 15:03:45 2025 From: duke at openjdk.org (duke) Date: Tue, 2 Sep 2025 15:03:45 GMT Subject: RFR: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F [v6] In-Reply-To: References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: On Mon, 1 Sep 2025 09:03:24 GMT, Galder Zamarre?o wrote: >> I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations. >> >> Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows: >> >> >> Benchmark (seed) (size) Mode Cnt Base Patch Units Diff >> VectorBitConversion.doubleToLongBits 0 2048 thrpt 8 1168.782 1157.717 ops/ms -1% >> VectorBitConversion.doubleToRawLongBits 0 2048 thrpt 8 3999.387 7353.936 ops/ms +83% >> VectorBitConversion.floatToIntBits 0 2048 thrpt 8 1200.338 1188.206 ops/ms -1% >> VectorBitConversion.floatToRawIntBits 0 2048 thrpt 8 4058.248 14792.474 ops/ms +264% >> VectorBitConversion.intBitsToFloat 0 2048 thrpt 8 3050.313 14984.246 ops/ms +391% >> VectorBitConversion.longBitsToDouble 0 2048 thrpt 8 3022.691 7379.360 ops/ms +144% >> >> >> The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control. >> >> I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions. > > Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: > > Adjust vector size expectations @galderz Your change (at version 632408ba2adf8f3bffe226a9c2bb0db022d4e8d1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26457#issuecomment-3245723721 From jwaters at openjdk.org Tue Sep 2 15:06:42 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 2 Sep 2025 15:06:42 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: <_JgH1bMAGxiue2ou0w7d57FsUzMu8c2XkfXOtESeZb8=.68d0423b-a0a0-4ea0-ae82-b8c9a4f81c11@github.com> On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. Please get this in as soon as possible. ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/27050#pullrequestreview-3176979619 From psandoz at openjdk.org Tue Sep 2 15:26:45 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 2 Sep 2025 15:26:45 GMT Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build In-Reply-To: <2REfnawHIfGgnFBrEQMb2vDBkUjLNnzbFRV726KSOJ0=.c7a05f23-3268-4261-8a8a-a503824a8fc0@github.com> References: <2REfnawHIfGgnFBrEQMb2vDBkUjLNnzbFRV726KSOJ0=.c7a05f23-3268-4261-8a8a-a503824a8fc0@github.com> Message-ID: On Mon, 1 Sep 2025 16:57:35 GMT, Jorn Vernee wrote: > @PaulSandoz Do you know if there was/is a particular reason for not generating the VarHandle guards as part of the build? At the time there were other priorities and we did not know what the frequency of updates might be, but we left gen code in place just in case (and did use it occasionally). I think this PR is good, addressing tech debt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27009#issuecomment-3245808429 From vyazici at openjdk.org Tue Sep 2 15:29:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 15:29:52 GMT Subject: RFR: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: <8Tf_P9myzruQetqPKRfcN1u4wj1_9b3J--k08F6JKbg=.5a08e454-15c0-4413-ae5f-7ae577b64732@github.com> On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. `tier1` passes on several platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27050#issuecomment-3245815752 From vyazici at openjdk.org Tue Sep 2 15:29:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Sep 2025 15:29:53 GMT Subject: Integrated: 8366693: Backout recent JavaLangAccess changes breaking the build In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:11:04 GMT, Volkan Yazici wrote: > Recently merged JDK-8356439, renaming `JavaLangAccess::*NoRepl` methods, has conflicting changes with JDK-8362893 slightly preceding it. Back out JDK-8356439 by reverting eea50fbc1b2. This pull request has now been integrated. Changeset: ecf05ca5 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/ecf05ca541b32736ab8e8a38d4be4f037a56361d Stats: 462 lines in 8 files changed: 122 ins; 242 del; 98 mod 8366693: Backout recent JavaLangAccess changes breaking the build Reviewed-by: jpai, serb, alanb, syan, rriggs, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/27050 From headius at headius.com Tue Sep 2 15:31:12 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 2 Sep 2025 10:31:12 -0500 Subject: MethodHandles.lookup errors where publicLookup is ok Message-ID: I've run into various versions of this situation and I wonder if my expectations about MethodHandles.lookup vs publicLookup are flawed. This issue shows an IllegalAccessException "symbolic reference class is not accessible: class jdk.proxy4.$Proxy49" when using a Lookup produced by MethodHandles.lookup, but it works correctly when using publicLookup: https://github.com/jruby/jruby/issues/8987#issuecomment-3245803956 My expectation would be that if publicLookup works, then lookup should also work. I've filed a similar issue in the past (unresolved) where I was forced to use publicLookup instead of lookup: https://bugs.openjdk.org/browse/JDK-8313913 The error is similar here, but I'm not sure if it's related (module system should have been fully booted by the time of the JRuby failure). If my expectation is correct, this is a new version of the bug and I can file an issue. It's happening at least as late as JDK 24.0.2. If my expectation is not correct, please explain to me how I can know whether lookup will produce errors when publicLookup does not. *Charles Oliver Nutter* *Architect and Technologist* Headius Enterprises https://www.headius.com headius at headius.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From psandoz at openjdk.org Tue Sep 2 15:32:50 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 2 Sep 2025 15:32:50 GMT Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 19:13:27 GMT, Chen Liang wrote: > Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class. > > This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too. > > Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData. > >
> > Diff from new to old (backwards): > > > > liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > index 13ef65b..49408a2 100644 > --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java > +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer; > import jdk.internal.vm.annotation.ForceInline; > import jdk.internal.vm.annotation.Hidden; > > -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator. > -// Do not edit! > +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit. > @AOTSafeClassInitializer > final class VarHandleGuards { > > > >
> > Testing: java/lang/invoke. Looks good. Suggested fixes for a few typos that I think were present in the original documentation. make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 53: > 51: *

> 52: * The generated class essentially encapsulates pre-compiled LambdaForms, > 53: * one for each method, for the most set of common method signatures. Suggestion: * one for each method, for common method signatures. make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 64: > 62: * long, float, double), and 3 shapes then a maximum of 60 methods will be > 63: * generated. However, the number is likely to be less since there > 64: * be duplicate signatures. Suggestion: * will be duplicate signatures. ------------- Marked as reviewed by psandoz (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27009#pullrequestreview-3177077405 PR Review Comment: https://git.openjdk.org/jdk/pull/27009#discussion_r2316436550 PR Review Comment: https://git.openjdk.org/jdk/pull/27009#discussion_r2316438118 From duke at openjdk.org Tue Sep 2 15:50:59 2025 From: duke at openjdk.org (Vanitha B P) Date: Tue, 2 Sep 2025 15:50:59 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v2] In-Reply-To: References: <2LPtj3TfEBNxn52lApbp5klrVVW2DZ-bG2nApVAgEoY=.711dc754-ef17-4139-a3b3-cb5666b71324@github.com> Message-ID: On Tue, 2 Sep 2025 14:35:47 GMT, Mikhail Yankelevich wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> modified tzid variable > > test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 111: > >> 109: panel.setLayout(new BoxLayout(panel, BoxLayout.PAGE_AXIS)); >> 110: // Time zone ID label >> 111: var tzid = new JLabel("Time zone ID: " + SDF.getTimeZone().getID(), SwingConstants.CENTER); > > minor: do you think changing it to a more intuitive `timeZoneID` would make it easier to read? If you want to leave it as is - I don't mind Done, changed to timeZoneID. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27043#discussion_r2316501052 From duke at openjdk.org Tue Sep 2 15:50:58 2025 From: duke at openjdk.org (Vanitha B P) Date: Tue, 2 Sep 2025 15:50:58 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v3] In-Reply-To: References: Message-ID: > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: changed tzid to more readable timeZoneID ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27043/files - new: https://git.openjdk.org/jdk/pull/27043/files/7a2a87d3..1d553994 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From chen.l.liang at oracle.com Tue Sep 2 15:56:26 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Tue, 2 Sep 2025 15:56:26 +0000 Subject: MethodHandles.lookup errors where publicLookup is ok In-Reply-To: References: Message-ID: Hi Charlie, This is definitely a bug in the JDK, but I need more investigation to ensure if the issue lies in Lookup or Proxy. I guess this might relate to the fact that proxy dynamic modules are open to java.base as an implementation artifact, because the public lookup has Object.class as its lookup class. Since proxy has different module configurations depending on whether it has module-private or package-private interfaces, can you share a minimal setup where you can replicate this issue? I tried replicating on: Proxy.newProxyInstance(ClassLoader.getSystemClassLoader(), new Class []{Runnable.class}, (_, _, _) -> {return null;}) In jshell, and failed to replicate your failure with Lookup::accessClass. Regards, Chen Liang ________________________________ From: core-libs-dev on behalf of Charles Oliver Nutter Sent: Tuesday, September 2, 2025 10:31 AM To: core-libs-dev at openjdk.org Subject: MethodHandles.lookup errors where publicLookup is ok I've run into various versions of this situation and I wonder if my expectations about MethodHandles.lookup vs publicLookup are flawed. This issue shows an IllegalAccessException "symbolic reference class is not accessible: class jdk.proxy4.$Proxy49" when using a Lookup produced by MethodHandles.lookup, but it works correctly when using publicLookup: https://github.com/jruby/jruby/issues/8987#issuecomment-3245803956 My expectation would be that if publicLookup works, then lookup should also work. I've filed a similar issue in the past (unresolved) where I was forced to use publicLookup instead of lookup: https://bugs.openjdk.org/browse/JDK-8313913 The error is similar here, but I'm not sure if it's related (module system should have been fully booted by the time of the JRuby failure). If my expectation is correct, this is a new version of the bug and I can file an issue. It's happening at least as late as JDK 24.0.2. If my expectation is not correct, please explain to me how I can know whether lookup will produce errors when publicLookup does not. Charles Oliver Nutter Architect and Technologist Headius Enterprises https://www.headius.com headius at headius.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Tue Sep 2 16:05:11 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 2 Sep 2025 17:05:11 +0100 Subject: MethodHandles.lookup errors where publicLookup is ok In-Reply-To: References: Message-ID: On 02/09/2025 16:31, Charles Oliver Nutter wrote: > I've run into various versions of this situation and I wonder if my > expectations about MethodHandles.lookup vs publicLookup are flawed. > > This issue shows an IllegalAccessException "symbolic reference class > is not accessible: class jdk.proxy4.$Proxy49" when using a Lookup > produced by MethodHandles.lookup, but it works correctly when using > publicLookup: > publicLookup has UNCONDITIONAL access so it assumes readability (like core reflection). The lookup object obtained with MethodsHandles.lookup does not so there may be cases where the caller needs to use Module.addReads to add the read edge at runtime. I can't tell if this is what you are running it but if you could create a small test case then it might be possible to diagnose (the linked JBS issue seems to be using JDK 8 so pre-dates modules and the encapsulation of proxy classes). -Alan From bpb at openjdk.org Tue Sep 2 16:05:31 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Sep 2025 16:05:31 GMT Subject: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v3] In-Reply-To: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> References: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> Message-ID: > Attempt to improve the verbiage of the `java.io.File` specification to make it clearer whether a given method operates only on an abstract pathname or on the actual file system entry it denotes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8366102: pathnam -> pathname ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27006/files - new: https://git.openjdk.org/jdk/pull/27006/files/5b970ebc..b896d8c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27006&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27006&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27006/head:pull/27006 PR: https://git.openjdk.org/jdk/pull/27006 From bpb at openjdk.org Tue Sep 2 16:05:32 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Sep 2025 16:05:32 GMT Subject: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v2] In-Reply-To: References: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> Message-ID: On Sat, 30 Aug 2025 06:59:37 GMT, Alan Bateman wrote: > So a suggestion, mull over it [...]. I think anything clear and consistent will work; will investigate. > just a typo in "pathnam" at the end. I must've been flashing on the deprecated `tmpnam` call. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27006#issuecomment-3245941224 PR Review Comment: https://git.openjdk.org/jdk/pull/27006#discussion_r2316540748 From naoto at openjdk.org Tue Sep 2 16:10:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 16:10:44 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 18:00:25 GMT, Justin Lu wrote: > This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. > > Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. There are some tests for serializing DecimalFormatSymbols, but I agree that it would be desirable to revisit and cover missing cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27008#issuecomment-3245960204 From headius at headius.com Tue Sep 2 16:22:27 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 2 Sep 2025 11:22:27 -0500 Subject: MethodHandles.lookup errors where publicLookup is ok In-Reply-To: References: Message-ID: On Tue, Sep 2, 2025 at 10:56?AM Chen Liang wrote: > Hi Charlie, > This is definitely a bug in the JDK, but I need more investigation to > ensure if the issue lies in Lookup or Proxy. I guess this might relate to > the fact that proxy dynamic modules are open to java.base as an > implementation artifact, because the public lookup has Object.class as its > lookup class. > > Since proxy has different module configurations depending on whether it > has module-private or package-private interfaces, can you share a minimal > setup where you can replicate this issue? I tried replicating on: > > Proxy.newProxyInstance(ClassLoader.getSystemClassLoader(), new Class > []{Runnable.class}, (_, _, _) -> {return null;}) > > In jshell, and failed to replicate your failure with Lookup::accessClass. > I will try to come up with a non-JRuby reproduction, but I'm not sure when I'll get around to that. JRuby itself runs as a module and both the `lookup()` and `findVirtual()` for the Proxy's method implementation would be happening from within that modularized code. I would expect that your reproduction attempt should demonstrate the error if `lookup().findVirtual()` happened from an external (non-java.base) module. The reproduction with JRuby is simple... unpack the 10.0.2.0 tarball from jruby.org or run "./mvnw" in a JRuby git checkout, then "bin/jruby example.rb" should demonstrate the problem using the short reproduction code I provided here: https://github.com/jruby/jruby/issues/8987#issuecomment-3245755989 Note that my naive attempt to convert all `lookup()` along this path in JRuby to `publicLookup()` did indeed break a bunch of other cases where "more than public" access is needed for findVirtual/findStatic: https://github.com/jruby/jruby/pull/8989 This is the sort of situation I hoped to avoid by using `lookup()` under the expectation that it would treat all `find*` as though they were accessed naturally (i.e. not via java.lang.invoke) from that point in the surrounding class. > publicLookup has UNCONDITIONAL access so it assumes readability (like > core reflection). The lookup object obtained with MethodsHandles.lookup > does not so there may be cases where the caller needs to use > Module.addReads to add the read edge at runtime. I can't tell if this is > what you are running it but if you could create a small test case My first thought after reading this was that perhaps I should be using `unreflect` rather than doing my own `findVirtual` but since that requires a Lookup object I'd expect I'm right back in the same situation. - Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Tue Sep 2 16:23:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 16:23:46 GMT Subject: RFR: 8359174: tools/jlink/JLink20000Packages.java timed out [v8] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 14:27:28 GMT, Henry Jen wrote: >> Create a jar directly from the memory instead of real file, this should reduce the I/O overhead which likely the reason for the time out. >> The issue is not reproducible locally, and fails intermittently, so we simply trying to reduce time needed. >> The jar file created is verified manually running jtreg with retain=all. > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge openjdk/master > - Merge openjdk/master' into JDK-8359174 > - Clean up module dependencies > - Clean up jtreg directives > - Adapt review feedbacks > - Update copyright year > - Update copyright year > - cleanup > - 8359174: tools/jlink/JLink20000Packages.java timed out test/jdk/tools/jlink/JLink20000Packages.java line 57: > 55: * jdk.jlink/jdk.tools.jimage > 56: * @build tests.* > 57: * @run main/othervm/timeout=1920 -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal JLink20000Packages Hello Henry, I think we should remove this `timeout=1920`. It should no longer be needed after your changes in this PR. That large value was recently added when the default timeout factor was changed from 4 to 1 in mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25981#discussion_r2316587656 From naoto at openjdk.org Tue Sep 2 16:29:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 16:29:32 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: References: Message-ID: > Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Refining comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26973/files - new: https://git.openjdk.org/jdk/pull/26973/files/f79c5a08..ff7e9e0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=03-04 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26973/head:pull/26973 PR: https://git.openjdk.org/jdk/pull/26973 From naoto at openjdk.org Tue Sep 2 16:29:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 16:29:32 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v2] In-Reply-To: <_W1WPjGtzVggv4acbIwM0uK4YUC_t_VpobbTy82Eyyk=.7da6e0d9-a746-429b-aac9-361ab5cf7778@github.com> References: <_W1WPjGtzVggv4acbIwM0uK4YUC_t_VpobbTy82Eyyk=.7da6e0d9-a746-429b-aac9-361ab5cf7778@github.com> Message-ID: On Sat, 30 Aug 2025 05:51:15 GMT, Stuart Marks wrote: > It would be good to add comments that describes this precondition. Good point. Explained it in its comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2316599042 From rriggs at openjdk.org Tue Sep 2 16:34:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 2 Sep 2025 16:34:45 GMT Subject: RFR: 8365467: Issues with jrtfs implementation for exploded run-time images [v2] In-Reply-To: <2viHL6KuT_VV5Mrijdf68M2tLJptIvinHW9fZCErqTg=.e2e44843-55a1-4ef3-91e2-4201f2c8698c@github.com> References: <2viHL6KuT_VV5Mrijdf68M2tLJptIvinHW9fZCErqTg=.e2e44843-55a1-4ef3-91e2-4201f2c8698c@github.com> Message-ID: <3AqBtrqcn95GA-4bkr1LhgjWyOCRXtloDlATa3JZVxY=.08733708-7b6a-4151-9d6f-99d1137f7763@github.com> On Fri, 29 Aug 2025 08:49:27 GMT, David Beaumont wrote: >> This PR addresses several issues found while adding unit tests for ExplodedImage. >> I have added review comments for changes (some of which are a little preferential, but bring the code into line with things like ImageReader in terms of the name choices for variables). >> Later it is likely that this code will be adapted for the up-coming preview mode support in Valhalla, so having it unit-testable is important. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Feedback tweaks. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26757#pullrequestreview-3177340757 From rriggs at openjdk.org Tue Sep 2 16:36:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 2 Sep 2025 16:36:44 GMT Subject: RFR: 8366298: FDLeakTest sometimes takes minutes to complete on Linux [v3] In-Reply-To: References: Message-ID: <3uRo3qkVvrCvgTr3hbIFYYiJIgA9Y895QoMO_bYQWmY=.6d697a6c-35be-4958-b468-b9b5971f6d31@github.com> On Tue, 2 Sep 2025 08:03:27 GMT, Stefan Karlsson wrote: >> While investigating [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on Linux. >> >> The reason is that the test performs a `fcntl` call for each and every potential file descriptor number. This can be a large number of calls and sometimes results in minutes-long test executions. >> >> I propose that we fix this by limiting the max number of open file descriptors. This lowers the test execution time to about 1 second. >> >> The test has two processes. One that executes the libFDLeaker.c code below as an agent in the test JVM, then it forks into a exeFDLeakTester.c, which reads the property `int max_fd = (int)sysconf(_SC_OPEN_MAX);`. The setting of `RLIMIT_NOFILE` to `100` lowers `max_fd` to `100`. I've verified this on both Linux and on macOS. >> >> I've run the test manually on Linux and macOS and verified that it runs faster. I've also run this through tier1. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Remove jtreg timeouts > - Merge remote-tracking branch 'upstream/master' into 8366298_fdleaktest > - Add error logging > - 8366298: FDLeakTest sometimes takes minutes to complete on Linux looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26979#pullrequestreview-3177347786 From henryjen at openjdk.org Tue Sep 2 16:50:27 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 2 Sep 2025 16:50:27 GMT Subject: RFR: 8359174: tools/jlink/JLink20000Packages.java timed out [v9] In-Reply-To: References: Message-ID: > Create a jar directly from the memory instead of real file, this should reduce the I/O overhead which likely the reason for the time out. > The issue is not reproducible locally, and fails intermittently, so we simply trying to reduce time needed. > The jar file created is verified manually running jtreg with retain=all. Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Remove timeout from merge - Merge remote-tracking branch 'refs/remotes/openjdk/master' into JDK-8359174 - Merge openjdk/master - Merge openjdk/master' into JDK-8359174 - Clean up module dependencies - Clean up jtreg directives - Adapt review feedbacks - Update copyright year - Update copyright year - cleanup - ... and 1 more: https://git.openjdk.org/jdk/compare/ecf05ca5...28a6d5b7 ------------- Changes: https://git.openjdk.org/jdk/pull/25981/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25981&range=08 Stats: 124 lines in 2 files changed: 56 ins; 45 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/25981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25981/head:pull/25981 PR: https://git.openjdk.org/jdk/pull/25981 From henryjen at openjdk.org Tue Sep 2 16:50:29 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 2 Sep 2025 16:50:29 GMT Subject: RFR: 8359174: tools/jlink/JLink20000Packages.java timed out [v8] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 16:20:57 GMT, Jaikiran Pai wrote: >> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Merge openjdk/master >> - Merge openjdk/master' into JDK-8359174 >> - Clean up module dependencies >> - Clean up jtreg directives >> - Adapt review feedbacks >> - Update copyright year >> - Update copyright year >> - cleanup >> - 8359174: tools/jlink/JLink20000Packages.java timed out > > test/jdk/tools/jlink/JLink20000Packages.java line 57: > >> 55: * jdk.jlink/jdk.tools.jimage >> 56: * @build tests.* >> 57: * @run main/othervm/timeout=1920 -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal JLink20000Packages > > Hello Henry, I think we should remove this `timeout=1920`. It should no longer be needed after your changes in this PR. That large value was recently added when the default timeout factor was changed from 4 to 1 in mainline. ok, it was from the merge and I agree we can take away this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25981#discussion_r2316642423 From jpai at openjdk.org Tue Sep 2 16:53:49 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 16:53:49 GMT Subject: RFR: 8359174: tools/jlink/JLink20000Packages.java timed out [v9] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 16:50:27 GMT, Henry Jen wrote: >> Create a jar directly from the memory instead of real file, this should reduce the I/O overhead which likely the reason for the time out. >> The issue is not reproducible locally, and fails intermittently, so we simply trying to reduce time needed. >> The jar file created is verified manually running jtreg with retain=all. > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Remove timeout from merge > - Merge remote-tracking branch 'refs/remotes/openjdk/master' into JDK-8359174 > - Merge openjdk/master > - Merge openjdk/master' into JDK-8359174 > - Clean up module dependencies > - Clean up jtreg directives > - Adapt review feedbacks > - Update copyright year > - Update copyright year > - cleanup > - ... and 1 more: https://git.openjdk.org/jdk/compare/ecf05ca5...28a6d5b7 Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25981#pullrequestreview-3177397560 From smarks at openjdk.org Tue Sep 2 17:00:51 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 2 Sep 2025 17:00:51 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v13] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 03:59:37 GMT, Liam Miller-Cushon wrote: >> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Add an implementation comment to AbstractImmutableMap My turn to keep this open. :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-3246112175 From naoto at openjdk.org Tue Sep 2 17:04:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 17:04:46 GMT Subject: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 In-Reply-To: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> Message-ID: <7Dkg3RT7FqyGD32gIbhB5uu-SvTy02SXCPah2dVLbaA=.8dc7a5e2-5f8d-4937-89af-f287bc5e7ddd@github.com> On Fri, 29 Aug 2025 23:59:54 GMT, Justin Lu wrote: > This PR addresses a JCK test failure of an unexpected SIOOBE during DecimalFormat parsing. During the char by char comparison in `matchAffix`, the minimum of the length of the parsed String and the PP index + affix length are iterated on. The parse position index needs to be checked to not be negative to ensure that we do not index the String below 0. Taking the minimum of those two previously mentioned values already guarantees that we do not index the String above the length. test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 172: > 170: assertNull(assertDoesNotThrow(() -> new DecimalFormat().parse("1", new ParsePosition(-1)))); > 171: } > 172: Thanks for writing the invalid case test. As Alan suggested, maybe we could provide more edge case tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27014#discussion_r2316676697 From alan.bateman at oracle.com Tue Sep 2 17:11:54 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 2 Sep 2025 18:11:54 +0100 Subject: MethodHandles.lookup errors where publicLookup is ok In-Reply-To: References: Message-ID: <76593135-89db-41ef-a493-5dd60e873e09@oracle.com> On 02/09/2025 17:22, Charles Oliver Nutter wrote: > > > publicLookup has UNCONDITIONAL access so it assumes readability (like > > core reflection). The lookup object obtained with MethodsHandles.lookup > > does not so there may be cases where the caller needs to use > > Module.addReads to add the read edge at runtime. I can't tell if this is > > what you are running it but if you could create a small test case > > My first thought after reading this was that perhaps I should be using > `unreflect` rather than doing my own `findVirtual` but since that > requires a Lookup object I'd expect I'm right back in the same situation. > The access check fails because org.jruby.dist does not read jdk.proxy3. If you invoke j.l.Module.addReads(proxyClass.getModule()) from code in org.jruby.dist then it will add the read edge. Can you try that? As regards diagnosing this then I think we need improve the IllegalAccessExceptions exception messages. A lot of effort went into JDK 9 to ensure that the IAE thrown in the core reflection access spelled out the reason why the access check failed. Most reflection based frameworks used core reflection at the time. We should have put more effort into the having the IAE exception messages in j.l.invoke as "is not accessible" makes it hard to diagnose. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Tue Sep 2 17:14:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 17:14:52 GMT Subject: RFR: 8366375: Collator example for SECONDARY uses wrong code point In-Reply-To: <1V62DK45EFkzOcxzaZDM9vY6PPJ-NvdCYkxPNwd4iMs=.3fab04a5-4992-4785-8209-960536b203ae@github.com> References: <1V62DK45EFkzOcxzaZDM9vY6PPJ-NvdCYkxPNwd4iMs=.3fab04a5-4992-4785-8209-960536b203ae@github.com> Message-ID: On Fri, 29 Aug 2025 16:47:14 GMT, Naoto Sato wrote: > Minor documentation corrections in Collator Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27007#issuecomment-3246147346 From naoto at openjdk.org Tue Sep 2 17:14:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 17:14:53 GMT Subject: Integrated: 8366375: Collator example for SECONDARY uses wrong code point In-Reply-To: <1V62DK45EFkzOcxzaZDM9vY6PPJ-NvdCYkxPNwd4iMs=.3fab04a5-4992-4785-8209-960536b203ae@github.com> References: <1V62DK45EFkzOcxzaZDM9vY6PPJ-NvdCYkxPNwd4iMs=.3fab04a5-4992-4785-8209-960536b203ae@github.com> Message-ID: On Fri, 29 Aug 2025 16:47:14 GMT, Naoto Sato wrote: > Minor documentation corrections in Collator This pull request has now been integrated. Changeset: c935d1ce Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/c935d1ce1c42ce98cc6ceffaa4f47eb2dba24dfd Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8366375: Collator example for SECONDARY uses wrong code point Reviewed-by: jlu, joehw, smarks ------------- PR: https://git.openjdk.org/jdk/pull/27007 From stuart.marks at oracle.com Tue Sep 2 17:54:14 2025 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 2 Sep 2025 10:54:14 -0700 Subject: [External] : Re: Q: List.of(E... elements) specification with regards to underlying array updates In-Reply-To: References: Message-ID: <88168e05-a1b7-4d6a-8924-518d41d9aa6f@oracle.com> On 9/2/25 5:00 AM, Eirik Bj?rsn?s wrote: > On Tue, Sep 2, 2025 at 1:46?PM Eirik Bj?rsn?s wrote: > >> Interestingly, List.copyOf [4] explicitly specifies that modifications >> to the given Collection are not reflected in the returned List. (Even >> when this may be inferred from the method name!). This prose is what I >> feel may be missing from List.of(E... elements). > > TLDR: > > I think my long-winded question boils down to: > > Should we add something like the following to List.of(E... elements): > > * If the given array is subsequently modified, the returned List will not > * reflect such modifications. > > This would clarify this aspect and provide parity with List.copyOf. If somebody is genuinely confused by the situation, we could add some clarifications. I'll observe though that the Java API specifications rely on the reader to have a lot of implicit knowledge. In a sense, this is a weakness of the specifications. But if we didn't rely on implicit knowledge, the specifications would be unbearably cumbersome and verbose. The implicit knowledge I'm referring to is that, in general, the internal state of objects in the API is rarely aliased with the state of other objects. This is so pervasive that it's hardly stated anywhere. Arrays.asList is a notable exception, which is why people find it confusing, and it's why Venkat and others (including me!) talk about this issue in presentations. The various collections views (e.g., subList, Map.entrySet, etc.) are also exceptions, and the specs go to some effort to make this clear -- because they're exceptional cases. The reason that List.copyOf's spec is explicit about modifications is that it needs to specify that it "makes a copy" while sometimes being allowed not to make a copy! That is, we wanted to allow List.copyOf to return its argument if the argument is unmodifiable. However, we didn't want to specify the exact circumstances under which this occurs. For the same reason, we didn't want to specify that List.copyOf always makes a copy, as it would preclude this optimization. The "modifications are not reflected" clause is a bit of specification language that allows us to split the difference. We avoid making any statements about the identity of the returned object, but we preserve essential behavior that a mutable collection is copied. This mostly doesn't apply to List.of(...) though it can if you look really hard. Most people's experience of List.of is something like var list = List.of(a, b, c, ..., x, y, z); It's hard to interpret a clause that says "if the given array is subsequently modified..." because no arrays are visible here. To understand it, you need to know that (1) the "given" array is the implicitly generated array that results from a varargs call, and (2) the implementation of lists created by List.of larger than a certain size use an array to store their elements. Given this knowledge that there are two arrays, such a clause would be sensible in that it would require the arrays not to be aliased. However, without providing all this context, I'm skeptical that adding such a clause would provide much value. s'marks From henryjen at openjdk.org Tue Sep 2 18:05:49 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 2 Sep 2025 18:05:49 GMT Subject: Integrated: 8359174: tools/jlink/JLink20000Packages.java timed out In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:38:03 GMT, Henry Jen wrote: > Create a jar directly from the memory instead of real file, this should reduce the I/O overhead which likely the reason for the time out. > The issue is not reproducible locally, and fails intermittently, so we simply trying to reduce time needed. > The jar file created is verified manually running jtreg with retain=all. This pull request has now been integrated. Changeset: 0d85f076 Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/0d85f076cc32494c1162baea3ea6b0db67136d41 Stats: 124 lines in 2 files changed: 56 ins; 45 del; 23 mod 8359174: tools/jlink/JLink20000Packages.java timed out Co-authored-by: Vicente Romero Co-authored-by: Eirik Bj?rsn?s Reviewed-by: jpai, liach ------------- PR: https://git.openjdk.org/jdk/pull/25981 From shaunspiller at gmail.com Tue Sep 2 18:19:58 2025 From: shaunspiller at gmail.com (Shaun Spiller) Date: Tue, 2 Sep 2025 19:19:58 +0100 Subject: Excessive copying of Collection.toArray() Message-ID: Hello! Please consider the following real utility method I have: /** * Returns an immutable list via {@link List#of} that is the * sorted content of the collection. */ public static @NonNull List sortedImmutableList( @NonNull Collection col, @Nullable Comparator comparator) { ArrayList list = new ArrayList<>(col); list.sort(comparator); return List.copyOf(list); } Quiz question: Assume this method is invoked with a large HashSet as its collection argument. How many ARRAY copies of the collection are created by this method? Clearly there must be at least one for the result, held internally in the immutable list. Any others? (Scroll for the answer.) . . . . . . . . . . . . . . . . . . . I was surprised to realize the answer is four: 1. ArrayList calls toArray() on the HashSet. 2. ArrayList defensively copies the array to assign to its internal elementData field, because it doesn't trust HashSet. 3. List.copyOf calls toArray() on the ArrayList. 4. List.of defensively copies the array to assign to its internal elements field, because it doesn't trust ArrayList. It is quite possible to rewrite my particular utility method with a raw array instead of ArrayList, to eliminate 2 array copies, but this requires an icky unchecked cast, and by rights is the kind of thing that shouldn't be necessary anyway. ----- In general, this kind of excessive defensive copying is going on ALL THE TIME. The underlying nuisance is that a subclass of Collection could potentially override toArray() to keep a reference to the returned array and make mischief with it. (Also, for ArrayList, it would be a problem if the returned array were a subclass of Object[].) I did a search thru the JDK and found a slew of cases where code calls Collection.toArray() and then has to worry about defensively copying it -- or trying to avoid defensively copying it: - java.util.List.copyOf(Collection) -- avoids copying an existing List.of/copyOf list, but for any other collection it calls toArray() and then defensively copies it again - java.util.ArrayList(Collection) -- constructor has a special check `if (collection.getClass() == ArrayList.class)`, in which case it skips the defensive copy and trusts the result of toArray(), but it does not trust any other collection - java.util.Vector(Collection) -- constructor has the same optimization trick as ArrayList, where it trusts ArrayList, but creates a defensive copy for any other collection. Vector doesn't even trust itself! - java.util.PriorityQueue.initElementsFromCollection(Collection) -- has optimization for ArrayList, but no other collection - java.util.concurrent.PriorityBlockingQueue(Collection) -- has optimization for ArrayList, but no other collection - java.util.concurrent.CopyOnWriteArrayList(Collection) -- has optimizations for ArrayList and CopyOnWriteArrayList, but no other collection. - java.util.concurrent.CopyOnWriteArrayList.addAllAbsent(Collection) -- has optimization for ArrayList but no other collection. - java.util.stream.Collectors.toUnmodifiableList() -- this avoids an excess copy, but does so in a very complicated way - sun.awt.util.IdentityArrayList(Collection) -- this appears to be an old copy-paste of ArrayList except with identity indexOf; like pre-2020 ArrayList, it blindly trusts that `col.toArray()` returns a new array, although based on this class's extremely limited use there is no manifestable bug. - java.lang.invoke.MethodHandles.dropArguments/dropArgumentsToMatch -- these call `list.toArray()` and then clone the array unconditionally - java.time.zone.ZoneRules.of(...) -- calls `lastRules.toArray()` and then clones the array unconditionally ----- I would suggest that there should be an internal utility method for use in all these cases, something like: public static Object[] safeToArray(Collection c) { Object[] a = c.toArray(); if (!isTrusted(c)) { a = Arrays.copyOf(a, a.length, Object[].class); } return a; } The delicate issue then is: what is the correct design of "isTrusted"? The check must be fast, and not spoofable by classes outside the JDK. My first thought was to detect that the class is loaded by the bootstrap class loader: static boolean isTrusted(Collection c) { return c.getClass().getClassLoader() == null; } However, I now realize this is unwise because it would shift the burden of trust into **every** Collection class in the JDK, instead of into the classes that actually care about the result. For example, Collections.UnmodifiableCollection.toArray() simply returns the result of its internal `col.toArray()`, which immediately carves a hole the size of a bus thru the check. Perhaps better would be for classes to explicitly opt-in and say "Yes, I promise that my toArray() method is safe". Would a package-private marker interface work for this? I am not sure. Anyway, the point is that classes within the JDK should not need to create so many defensive copies of each other. Note that this is becoming more of an issue now that List.of is becoming a popular "go-to" list for many situations where ArrayList would traditionally have been used. The "only trust ArrayList" pattern was never ideal and is starting to age. This is my first post here so I apologize for oversights in formatting or etiquette. Thanks for reading. From naoto at openjdk.org Tue Sep 2 18:50:45 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 18:50:45 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v3] In-Reply-To: References: Message-ID: <5I7FdKVr3PH_8Fkwh87wAizc_efngMwxbv0YBsEIKec=.9c0e0b28-54d9-426c-9b7e-a138d6e2c935@github.com> On Tue, 2 Sep 2025 15:50:58 GMT, Vanitha B P wrote: >> Problem Statements: >> 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. >> 2. ZoneID was not displaying in the window as it is displaying in the lower releases. >> >> Test Results: >> jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java >> >> Passed: java/util/TimeZone/DefaultTimeZoneTest.java >> Test results: passed: 1 > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > changed tzid to more readable timeZoneID LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27043#pullrequestreview-3177729678 From jlu at openjdk.org Tue Sep 2 18:55:23 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 18:55:23 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v2] In-Reply-To: References: Message-ID: > This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. > > Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Nested class rename - Add JDK regression test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27008/files - new: https://git.openjdk.org/jdk/pull/27008/files/0ace8f6a..751d00be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=00-01 Stats: 262 lines in 1 file changed: 262 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27008/head:pull/27008 PR: https://git.openjdk.org/jdk/pull/27008 From jlu at openjdk.org Tue Sep 2 18:55:24 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 18:55:24 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 06:41:53 GMT, Alan Bateman wrote: >> This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. >> >> Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. > > Have you considered adding a unit or regression test to exercise DecimalFormatSymbols serialization? I assume this issue slipped through and was caught else where because the jdk repo doesn't have any tests for this. @AlanBateman @naotoj Initially I relied on the JCK test since this was a non-standard situation. But you are right that we should not have to rely on the JCK tests to discover an issue in the JDK, I've removed the `noreg-jck` label and added a serialization test. It checks all of the correct behavior based on the stream version, as well as other invariants. I also filed [JDK-8366733](https://bugs.openjdk.org/browse/JDK-8366733) because many of the existing serialization tests for DFS seem to be relics and can either be removed or are redundant with the newly added test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27008#issuecomment-3246431509 From eirbjo at gmail.com Tue Sep 2 19:07:58 2025 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 2 Sep 2025 21:07:58 +0200 Subject: [External] : Re: Q: List.of(E... elements) specification with regards to underlying array updates In-Reply-To: <88168e05-a1b7-4d6a-8924-518d41d9aa6f@oracle.com> References: <88168e05-a1b7-4d6a-8924-518d41d9aa6f@oracle.com> Message-ID: On Tue, Sep 2, 2025 at 7:54?PM Stuart Marks wrote: Thanks Stuart for your excellent essay of an answer :-) > If somebody is genuinely confused by the situation, we could add some > clarifications. I will confess that I was not genuinely confused. My assumption of an "unmodifiable list" would be that it should be immutable, be it through the front door or the back door. > But if we didn't rely on implicit knowledge, the specifications > would be unbearably cumbersome and verbose. This is a fair point and satisfied my actual confusion which was more about what is the right level of specification here. Where to stop. This seems to be a bit of an art. > The reason that List.copyOf's spec is explicit about modifications is that it needs > to specify that it "makes a copy" while sometimes being allowed not to make a copy! A side note: I assume this method would also simply be named "of" if overloading resolution was not an issue. > Most people's experience of List.of is something like > > var list = List.of(a, b, c, ..., x, y, z); I see your point. However, I think in fact people will mostly be using one of the non-varargs methods, since call sites with more than 10 elements look rare. At least in the OpenJDK source code, the vast majority calls this method with some actual array, not using varargs. This may be different in regular non-platform code though. But yes, even in the Javadoc itself it's not very clear that an array is involved, so talking about it would be more awkward compared to copyOf. > However, without providing all this context, I'm skeptical that > adding such a clause would provide much value. I think this makes sense and satisfies my curiosity. Thanks again for explaining! Eirik. From coffeys at openjdk.org Tue Sep 2 19:12:41 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 2 Sep 2025 19:12:41 GMT Subject: RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5> In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 14:33:03 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses a failure in `test/jdk/java/util/zip/ZipFile/ZipSourceCache.java` test? > > As noted in the description of https://bugs.openjdk.org/browse/JDK-8366439, this test fails if the underlying file system's timestamp granularity doesn't allow for the last modified timestamp to increase when the test's ZIP file is updated with newer content. > > The change in this PR updates the test to first check that the last modified timestamp has increased on the ZIP file that was updated, before running the rest of the test assertions. The test continues to pass in our CI with this change. thanks for looking at this @jaikiran - Do we have a product regression here with this env ? I'm thinking that a cached ZipFile$Source instance was returned from the `files` HashMap when a new one should have been created. The Source.hashCode() wasn't able to differentiate on the updated file due to to crude timestamps being returned from the buggy filesystem ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3246489204 From naoto at openjdk.org Tue Sep 2 19:35:57 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 19:35:57 GMT Subject: RFR: 8366517: DateFormatSymbols(Locale) throws NPE if Locale argument is null Message-ID: Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/27060/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27060&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366517 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27060/head:pull/27060 PR: https://git.openjdk.org/jdk/pull/27060 From headius at headius.com Tue Sep 2 19:36:52 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 2 Sep 2025 14:36:52 -0500 Subject: MethodHandles.lookup errors where publicLookup is ok In-Reply-To: <76593135-89db-41ef-a493-5dd60e873e09@oracle.com> References: <76593135-89db-41ef-a493-5dd60e873e09@oracle.com> Message-ID: On Tue, Sep 2, 2025 at 12:12?PM Alan Bateman wrote: > The access check fails because org.jruby.dist does not read jdk.proxy3. If > you invoke j.l.Module.addReads(proxyClass.getModule()) from code in > org.jruby.dist then it will add the read edge. Can you try that? > This does fix the issue without resorting to `publicLookup()`. Thanks! However... why doesn't `findVirtual()` request read access to the given class's module before erroring? Presumably this is what the reflected call and the `publicLookup()` logic does. Worst case, it would raise an error because it cannot gain such access. If there's another down side to requesting read access automatically when read access is clearly required, I'd like to know about it... because now I have to do it manually anyway. As regards diagnosing this then I think we need improve the > IllegalAccessExceptions exception messages. A lot of effort went into JDK 9 > to ensure that the IAE thrown in the core reflection access spelled out the > reason why the access check failed. Most reflection based frameworks used > core reflection at the time. We should have put more effort into the having > the IAE exception messages in j.l.invoke as "is not accessible" makes it > hard to diagnose. > Raising an error saying it "is not accessible" is also rather misleading when it actually **is** accessible, but I have not (or the underlying API has not) explicitly requested that access. One of the most frustrating aspects of JPMS is the amount of times I have to explicitly request read access knowing it will be granted, like to silence warnings for unnnamed module accesses. The new patch combining `lookup()` with `addReads()` is running through CI now, but I expect it will pass. I do wonder about the overhead of us requesting read access every time we access a class through `MethodHandles.Lookup`, though. https://github.com/jruby/jruby/actions/runs/17413967057 - Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Tue Sep 2 20:23:26 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Sep 2025 20:23:26 GMT Subject: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v4] In-Reply-To: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> References: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> Message-ID: > Attempt to improve the verbiage of the `java.io.File` specification to make it clearer whether a given method operates only on an abstract pathname or on the actual file system entry it denotes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8366102: "denoted by" -> "located by" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27006/files - new: https://git.openjdk.org/jdk/pull/27006/files/b896d8c7..6d3587e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27006&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27006&range=02-03 Stats: 44 lines in 1 file changed: 0 ins; 0 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/27006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27006/head:pull/27006 PR: https://git.openjdk.org/jdk/pull/27006 From bpb at openjdk.org Tue Sep 2 20:23:26 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Sep 2025 20:23:26 GMT Subject: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v3] In-Reply-To: References: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> Message-ID: On Tue, 2 Sep 2025 16:05:31 GMT, Brian Burkhalter wrote: >> Attempt to improve the verbiage of the `java.io.File` specification to make it clearer whether a given method operates only on an abstract pathname or on the actual file system entry it denotes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8366102: pathnam -> pathname > So a suggestion [...] is to have the methods that access the file system use "the file located by this abstract pathname" That definitely is more precise to me. So changed in 6d3587e. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27006#issuecomment-3246672226 From naoto at openjdk.org Tue Sep 2 20:27:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 20:27:41 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 18:55:23 GMT, Justin Lu wrote: >> This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. >> >> Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Nested class rename > - Add JDK regression test Thanks for providing new tests. test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 140: > 138: } > 139: > 140: // Previous versions of DFS could contain a null locale "Previous" suggests it would not allow null with this change, which is not the case. test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 224: > 222: ObjectInputStream ois = new ObjectInputStream(byteArrayInputStream)) { > 223: return (DecimalFormatSymbols) ois.readObject(); > 224: } I guess if an error occured in this try block, the test should fail. Just wondering the reason it did not use `assertDoesNotThrow()` method. ------------- PR Review: https://git.openjdk.org/jdk/pull/27008#pullrequestreview-3177975352 PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317077376 PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317062931 From jlu at openjdk.org Tue Sep 2 20:38:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 20:38:42 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 20:22:50 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Nested class rename >> - Add JDK regression test > > test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 140: > >> 138: } >> 139: >> 140: // Previous versions of DFS could contain a null locale > > "Previous" suggests it would not allow null with this change, which is not the case. Instances created from the current standard _public_ API **do not allow** a null locale, hence the clarification that previous versions **can contain** a null locale. i.e. We do not expect to see null locales with up-to-date versions of DFS that are not tampered with, so I think the comment is accurate. > test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 224: > >> 222: ObjectInputStream ois = new ObjectInputStream(byteArrayInputStream)) { >> 223: return (DecimalFormatSymbols) ois.readObject(); >> 224: } > > I guess if an error occured in this try block, the test should fail. Just wondering the reason it did not use `assertDoesNotThrow()` method. I did not swallow the error with `assertDoesNotThrow()` here becasue `disagreeingTextTest` expects to see an `InvalidObjectException.class`. Future tests/changes can easily check for expected de-serialization failures with this setup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317106675 PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317106647 From jlu at openjdk.org Tue Sep 2 20:46:46 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 20:46:46 GMT Subject: RFR: 8365175: Replace Unicode extension anchor elements with link tag [v3] In-Reply-To: <0t5YDtu6ylWIPC8qsRpR49hwn6xGWRub8ebABKKD5DY=.42d97385-3974-4eb8-93da-da7ec64c274f@github.com> References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com> <0t5YDtu6ylWIPC8qsRpR49hwn6xGWRub8ebABKKD5DY=.42d97385-3974-4eb8-93da-da7ec64c274f@github.com> Message-ID: On Fri, 29 Aug 2025 20:44:00 GMT, Justin Lu wrote: >> This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683. >> >> This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > link -> linkplain Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26996#issuecomment-3246731929 From jlu at openjdk.org Tue Sep 2 20:46:47 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 20:46:47 GMT Subject: Integrated: 8365175: Replace Unicode extension anchor elements with link tag In-Reply-To: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com> References: <-Xpp4i_f9UglODJqIAJyt8seYC7GaFw1WN6z21CRgeI=.d94de2eb-e94b-4d36-b2d2-91a3930a5a58@github.com> Message-ID: On Thu, 28 Aug 2025 20:23:32 GMT, Justin Lu wrote: > This PR is a cleanup change which replaces anchor element references of the Locale `def_locale_extension` section with the Javadoc link tag. This is a doc only change and is a result of the discussion in the PR of https://github.com/openjdk/jdk/pull/26683. > > This includes one additional conversion of the `legacy_language_codes` section to get rid of all Locale.html anchor element references. This pull request has now been integrated. Changeset: 80fb7088 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/80fb7088a10136080d23ea93b4840f17d738500c Stats: 36 lines in 12 files changed: 0 ins; 0 del; 36 mod 8365175: Replace Unicode extension anchor elements with link tag Reviewed-by: liach, iris, naoto ------------- PR: https://git.openjdk.org/jdk/pull/26996 From naoto at openjdk.org Tue Sep 2 20:54:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 20:54:41 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 20:35:50 GMT, Justin Lu wrote: >> test/jdk/java/text/Format/DecimalFormat/DFSSerializationTest.java line 140: >> >>> 138: } >>> 139: >>> 140: // Previous versions of DFS could contain a null locale >> >> "Previous" suggests it would not allow null with this change, which is not the case. > > Instances created from the current standard _public_ API **do not allow** a null locale, hence the clarification that previous versions **can contain** a null locale. > > i.e. We do not expect to see null locales with up-to-date versions of DFS that are not tampered with, so I think the comment is accurate. I guess I mistook "previous" as previous implementation of DFS, but your comment refers to previous "stream" versions. Probably clarify it may help here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27008#discussion_r2317147454 From jlu at openjdk.org Tue Sep 2 21:02:46 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 21:02:46 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v3] In-Reply-To: References: Message-ID: <06XwUOKKgaicVdJcVCaOpuWBNE56acEtKeEYNNj2Y64=.e7328343-b82e-402c-b20e-e5525da7ef78@github.com> > This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. > > Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Clarify the null locale comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27008/files - new: https://git.openjdk.org/jdk/pull/27008/files/751d00be..445bbe85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27008/head:pull/27008 PR: https://git.openjdk.org/jdk/pull/27008 From jlu at openjdk.org Tue Sep 2 21:14:43 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 21:14:43 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 15:50:58 GMT, Vanitha B P wrote: >> Problem Statements: >> 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. >> 2. ZoneID was not displaying in the window as it is displaying in the lower releases. >> >> Test Results: >> jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java >> >> Passed: java/util/TimeZone/DefaultTimeZoneTest.java >> Test results: passed: 1 > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > changed tzid to more readable timeZoneID Thanks for the change. I ran the manual test and can confirm that the zone ID now updates in the window when the platform tz is changed. Nit: Copyright year can be updated. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/27043#pullrequestreview-3178145140 From jlu at openjdk.org Tue Sep 2 21:21:04 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 21:21:04 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v4] In-Reply-To: References: Message-ID: > This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. > > Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: public API is too broad ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27008/files - new: https://git.openjdk.org/jdk/pull/27008/files/445bbe85..dfb818c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27008&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27008/head:pull/27008 PR: https://git.openjdk.org/jdk/pull/27008 From jlu at openjdk.org Tue Sep 2 22:15:29 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 22:15:29 GMT Subject: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 [v2] In-Reply-To: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> Message-ID: > This PR addresses a JCK test failure of an unexpected SIOOBE during DecimalFormat parsing. During the char by char comparison in `matchAffix`, the minimum of the length of the parsed String and the PP index + affix length are iterated on. The parse position index needs to be checked to not be negative to ensure that we do not index the String below 0. Taking the minimum of those two previously mentioned values already guarantees that we do not index the String above the length. Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Missing the bug ID in the new test - Adding additional tests and moving tests to PositionTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27014/files - new: https://git.openjdk.org/jdk/pull/27014/files/79b57021..96f71a0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27014&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27014&range=00-01 Stats: 75 lines in 2 files changed: 56 ins; 14 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27014.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27014/head:pull/27014 PR: https://git.openjdk.org/jdk/pull/27014 From jlu at openjdk.org Tue Sep 2 22:15:30 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 22:15:30 GMT Subject: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 [v2] In-Reply-To: <7Dkg3RT7FqyGD32gIbhB5uu-SvTy02SXCPah2dVLbaA=.8dc7a5e2-5f8d-4937-89af-f287bc5e7ddd@github.com> References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> <7Dkg3RT7FqyGD32gIbhB5uu-SvTy02SXCPah2dVLbaA=.8dc7a5e2-5f8d-4937-89af-f287bc5e7ddd@github.com> Message-ID: On Tue, 2 Sep 2025 17:01:58 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Missing the bug ID in the new test >> - Adding additional tests and moving tests to PositionTest > > test/jdk/java/text/Format/NumberFormat/LenientParseTest.java line 172: > >> 170: assertNull(assertDoesNotThrow(() -> new DecimalFormat().parse("1", new ParsePosition(-1)))); >> 171: } >> 172: > > Thanks for writing the invalid case test. As Alan suggested, maybe we could provide more edge case tests. Added some additional tests with a focus on affix matching, specifically ensuring SIOOBE does not leak out in any of those cases. i.e. The bounds checks should ensure `false` is returned for those cases. But specifically for the failing JCK test, the main test we need on the JDK repo side is a negative ParsePosition index test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27014#discussion_r2317281582 From liach at openjdk.org Tue Sep 2 22:20:26 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Sep 2025 22:20:26 GMT Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build [v2] In-Reply-To: References: Message-ID: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com> > Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class. > > This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too. > > Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData. > >

> > Diff from new to old (backwards): > > > > liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > index 13ef65b..49408a2 100644 > --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java > +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer; > import jdk.internal.vm.annotation.ForceInline; > import jdk.internal.vm.annotation.Hidden; > > -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator. > -// Do not edit! > +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit. > @AOTSafeClassInitializer > final class VarHandleGuards { > > > >
> > Testing: java/lang/invoke. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Preexisting typos - Merge branch 'master' of https://github.com/openjdk/jdk into feature/build-vhguards - Restore order - 8366455: Move VarHandles.GuardMethodGenerator to execute on build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27009/files - new: https://git.openjdk.org/jdk/pull/27009/files/eea34487..2f344afa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27009&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27009&range=00-01 Stats: 5872 lines in 591 files changed: 2923 ins; 1274 del; 1675 mod Patch: https://git.openjdk.org/jdk/pull/27009.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27009/head:pull/27009 PR: https://git.openjdk.org/jdk/pull/27009 From naoto at openjdk.org Tue Sep 2 22:29:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 22:29:41 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 21:21:04 GMT, Justin Lu wrote: >> This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. >> >> Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > public API is too broad LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27008#pullrequestreview-3178334115 From naoto at openjdk.org Tue Sep 2 22:58:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Sep 2025 22:58:46 GMT Subject: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 [v2] In-Reply-To: References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> Message-ID: On Tue, 2 Sep 2025 22:15:29 GMT, Justin Lu wrote: >> This PR addresses a JCK test failure of an unexpected SIOOBE during DecimalFormat parsing. During the char by char comparison in `matchAffix`, the minimum of the length of the parsed String and the PP index + affix length are iterated on. The parse position index needs to be checked to not be negative to ensure that we do not index the String below 0. Taking the minimum of those two previously mentioned values already guarantees that we do not index the String above the length. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Missing the bug ID in the new test > - Adding additional tests and moving tests to PositionTest LGTM. Moving position tests unrelated to lenient minus parsing to here is good. test/jdk/java/text/Format/NumberFormat/PositionTest.java line 60: > 58: // begins at the valid portion. Ensure PP is properly updated. > 59: @Test > 60: public void modifiedPositionTest() { JUnit5 tests default to package-private visibility, but I think aligning with other tests is more important. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27014#pullrequestreview-3178377182 PR Review Comment: https://git.openjdk.org/jdk/pull/27014#discussion_r2317343019 From jlu at openjdk.org Tue Sep 2 23:10:41 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Sep 2025 23:10:41 GMT Subject: RFR: 8366517: DateFormatSymbols(Locale) throws NPE if Locale argument is null In-Reply-To: References: Message-ID: <8O740YRFXmkIrb1Hgu_qQUnYRSHYv0SWqXACpWWSOEc=.31959706-e26a-41fd-8a60-a99742e32e24@github.com> On Tue, 2 Sep 2025 19:29:37 GMT, Naoto Sato wrote: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. Looks good to me and the static factory methods already specify the NPE. fyi: PR title is missing the ` around code portions. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/27060#pullrequestreview-3178410659 From redestad at openjdk.org Tue Sep 2 23:44:42 2025 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 2 Sep 2025 23:44:42 GMT Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build [v2] In-Reply-To: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com> References: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com> Message-ID: On Tue, 2 Sep 2025 22:20:26 GMT, Chen Liang wrote: >> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class. >> >> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too. >> >> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData. >> >>
>> >> Diff from new to old (backwards): >> >> >> >> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> index 13ef65b..49408a2 100644 >> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java >> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer; >> import jdk.internal.vm.annotation.ForceInline; >> import jdk.internal.vm.annotation.Hidden; >> >> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator. >> -// Do not edit! >> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit. >> @AOTSafeClassInitializer >> final class VarHandleGuards { >> >> >> >>
>> >> Testing: java/lang/invoke. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Preexisting typos > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/build-vhguards > - Restore order > - 8366455: Move VarHandles.GuardMethodGenerator to execute on build Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27009#pullrequestreview-3178493622 From liach at openjdk.org Wed Sep 3 00:06:59 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 00:06:59 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v2] In-Reply-To: References: Message-ID: > java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. > > Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". > > However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. > > To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into doc/mh-holder-pregen - Ioi reviews - 8365428: Unclear comments on java.lang.invoke Holder classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27010/files - new: https://git.openjdk.org/jdk/pull/27010/files/723cf749..d65a56a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27010&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27010&range=00-01 Stats: 5993 lines in 599 files changed: 3013 ins; 1284 del; 1696 mod Patch: https://git.openjdk.org/jdk/pull/27010.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27010/head:pull/27010 PR: https://git.openjdk.org/jdk/pull/27010 From rriggs at openjdk.org Wed Sep 3 01:00:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 01:00:59 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 19:29:37 GMT, Naoto Sato wrote: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. src/java.base/share/classes/java/text/DateFormatSymbols.java line 148: > 146: * if the resources for the specified locale cannot be > 147: * found or cannot be loaded. > 148: * @throws NullPointerException if {@code locale} is null Adding an explicit Objects.requireNull(locale, "locale") would clearly identify when the NPE is thrown. Though it might be earlier than without the check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27060#discussion_r2317509928 From liach at openjdk.org Wed Sep 3 03:09:43 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 03:09:43 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v2] In-Reply-To: References: Message-ID: On Sun, 31 Aug 2025 18:18:20 GMT, Ioi Lam wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into doc/mh-holder-pregen >> - Ioi reviews >> - 8365428: Unclear comments on java.lang.invoke Holder classes > > src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 143: > >> 141: >> 142: /// Represents the "basic" types that exist in the JVM linkage and stack/locals. >> 143: /// All subwords (boolean, byte, char, short) are promoted to int. > > Existing: a few lines below. I think the `// all primitive types` comment should be deleted. > > > D_TYPE('D', double.class, Wrapper.DOUBLE, TypeKind.DOUBLE), // all primitive types Done. > src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1745: > >> 1743: /// ``` >> 1744: /// javap -c -p -v java.lang.invoke.LambdaForm\$Holder >> 1745: /// ``` > > Unfortunately, there's currently no way to use `javap` to display the contents of the re-generated version of the Holder classes in an AOT code. You can use `-Xlog:aot+map=trace`, but the information is not very easy to parse. > > I filed [JDK-8366485](https://bugs.openjdk.org/browse/JDK-8366485) - Display the contents of generated classes in AOT cache Sure, I have moved this info to a section specific to image building. We can add the AOT info later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2317640790 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2317641231 From iklam at openjdk.org Wed Sep 3 04:36:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 3 Sep 2025 04:36:48 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 00:06:59 GMT, Chen Liang wrote: >> java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. >> >> Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". >> >> However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. >> >> To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/mh-holder-pregen > - Ioi reviews > - 8365428: Unclear comments on java.lang.invoke Holder classes Looks good. Just a few small nits. src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 69: > 67: /// and behave identically to on-demand generated ones. Pregenerated lambda > 68: /// forms are resolved in [InvokerBytecodeGenerator#lookupPregenerated], which > 69: /// look up from the following 4 possibly-generated classes: which look up from the following 4 possibly-generated classes: -> which looks up methods in the following 4 possibly-generated classes: src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 91: > 89: /// process of the JDK. > 90: /// > 91: /// > To list all the Species classes in a JDK image: Should the `>` characters be deleted? src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 398: > 396: /// subject to change. > 397: /// > 398: /// @param traces the *traces* to determine the lambda forms and species the lambda forms and species -> the lambda forms and species to be generated. ------------- PR Review: https://git.openjdk.org/jdk/pull/27010#pullrequestreview-3178835555 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2317677840 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2317679614 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2317676497 From liach at openjdk.org Wed Sep 3 04:36:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 04:36:48 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 03:45:37 GMT, Ioi Lam wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into doc/mh-holder-pregen >> - Ioi reviews >> - 8365428: Unclear comments on java.lang.invoke Holder classes > > src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 91: > >> 89: /// process of the JDK. >> 90: /// >> 91: /// > To list all the Species classes in a JDK image: > > Should the `>` characters be deleted? These essentially act as a quote in markdown, like: > To list all the Species classes in a JDK image: > ``` > javap stuff > ``` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2317732301 From duke at openjdk.org Wed Sep 3 05:24:02 2025 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Sep 2025 05:24:02 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v4] In-Reply-To: References: Message-ID: <3ZZxxJN7so5fHtNVcmAktY-suviU-OrNfZejnuPBFRw=.7102d369-ab3d-46ec-a7d0-ef5ca4199d20@github.com> > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Copyright year changed to 2025 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27043/files - new: https://git.openjdk.org/jdk/pull/27043/files/1d553994..676cd48a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From jpai at openjdk.org Wed Sep 3 05:53:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Sep 2025 05:53:43 GMT Subject: RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5> In-Reply-To: References: Message-ID: <-ncJDkarXFF1QXX5Q8JL6Zw4FRy6r2Sq-Ru1yPhLH6Q=.8adde0f5-abe3-4439-aac4-46db36698a39@github.com> On Fri, 29 Aug 2025 14:33:03 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses a failure in `test/jdk/java/util/zip/ZipFile/ZipSourceCache.java` test? > > As noted in the description of https://bugs.openjdk.org/browse/JDK-8366439, this test fails if the underlying file system's timestamp granularity doesn't allow for the last modified timestamp to increase when the test's ZIP file is updated with newer content. > > The change in this PR updates the test to first check that the last modified timestamp has increased on the ZIP file that was updated, before running the rest of the test assertions. The test continues to pass in our CI with this change. Hello Sean, > thanks for looking at this @jaikiran - Do we have a product regression here with this env ? I don't think this is a product bug. > The Source.hashCode() wasn't able to differentiate on the updated file due to to crude timestamps being returned from the buggy filesystem ? The `java.util.zip.ZipFile` maintains an internal cache for an underlying ZIP file to read its CEN just once to try and avoid reading it every time a `ZipFile` instance is created. One internal implementation detail of that cache is that it has the ability to detect an update to the underlying ZIP file so that when a subsequent instance of `ZipFile` is created then it won't re-use an already cached CEN but instead will re-read the CEN (and cache it) afresh. To detect the updates to the ZIP file, it uses the last modified time of the file; and last modified timestamps have a granularity. My understanding is that filesystems are allowed to have different granularity of timestamps. In fact `java.io.File.lastModified()` has this API note: * @apiNote * While the unit of time of the return value is milliseconds, the * granularity of the value depends on the underlying file system and may * be larger. For example, some file systems use time stamps in units of * seconds. So it isn't a bug in the filesystem. Nor is it a bug in the `ZipFile` implementation's cache. In fact, in this test, if you introduce a delay of at least a second from the time ZIP file was modified to the time you created a new instance of `ZipFile`, the update would be noticed due to the last modified time changing and the CEN would be re-read afresh with a new entry in the internal cache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3247775712 From duke at openjdk.org Wed Sep 3 06:13:17 2025 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Sep 2025 06:13:17 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v5] In-Reply-To: References: Message-ID: > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: Vanitha B P ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27043/files - new: https://git.openjdk.org/jdk/pull/27043/files/676cd48a..c096a930 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27043&range=03-04 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27043/head:pull/27043 PR: https://git.openjdk.org/jdk/pull/27043 From eirbjo at openjdk.org Wed Sep 3 06:33:42 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 3 Sep 2025 06:33:42 GMT Subject: RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5> In-Reply-To: <-ncJDkarXFF1QXX5Q8JL6Zw4FRy6r2Sq-Ru1yPhLH6Q=.8adde0f5-abe3-4439-aac4-46db36698a39@github.com> References: <-ncJDkarXFF1QXX5Q8JL6Zw4FRy6r2Sq-Ru1yPhLH6Q=.8adde0f5-abe3-4439-aac4-46db36698a39@github.com> Message-ID: On Wed, 3 Sep 2025 05:51:03 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses a failure in `test/jdk/java/util/zip/ZipFile/ZipSourceCache.java` test? >> >> As noted in the description of https://bugs.openjdk.org/browse/JDK-8366439, this test fails if the underlying file system's timestamp granularity doesn't allow for the last modified timestamp to increase when the test's ZIP file is updated with newer content. >> >> The change in this PR updates the test to first check that the last modified timestamp has increased on the ZIP file that was updated, before running the rest of the test assertions. The test continues to pass in our CI with this change. > > Hello Sean, > >> thanks for looking at this @jaikiran - Do we have a product regression here with this env ? > > I don't think this is a product bug. > >> The Source.hashCode() wasn't able to differentiate on the updated file due to to crude timestamps being returned from the buggy filesystem ? > > The `java.util.zip.ZipFile` maintains an internal cache for an underlying ZIP file to read its CEN just once to try and avoid reading it every time a `ZipFile` instance is created. One internal implementation detail of that cache is that it has the ability to detect an update to the underlying ZIP file so that when a subsequent instance of `ZipFile` is created then it won't re-use an already cached CEN but instead will re-read the CEN (and cache it) afresh. To detect the updates to the ZIP file, it uses the last modified time of the file; and last modified timestamps have a granularity. > > My understanding is that filesystems are allowed to have different granularity of timestamps. In fact `java.io.File.lastModified()` has this API note: > > * @apiNote > * While the unit of time of the return value is milliseconds, the > * granularity of the value depends on the underlying file system and may > * be larger. For example, some file systems use time stamps in units of > * seconds. > > So it isn't a bug in the filesystem. Nor is it a bug in the `ZipFile` implementation's cache. In fact, in this test, if you introduce a delay of at least a second from the time ZIP file was modified to the time you created a new instance of `ZipFile`, the update would be noticed due to the last modified time changing and the CEN would be re-read afresh with a new entry in the internal cache. Hello @jaikiran I'm wondering if it would be better/simpler to manually update the last modification time of the first file created into the past post-creation, to avoid these granularity issues. Something like this after the first `createZipFile` call in `setup`: createZipFile("test1"); // Avoid file system granularity issues causing last modified time clash long oneMinuteAgo = absoluteFile.lastModified() - 60_000; absoluteFile.setLastModified(oneMinuteAgo); ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3247859215 From galder at openjdk.org Wed Sep 3 06:40:49 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Wed, 3 Sep 2025 06:40:49 GMT Subject: Integrated: 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F In-Reply-To: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> References: <0bYYOS5AYvN4ZD1xAGBRqV_xasw-np3JWKXC7WcGhyc=.74d97456-f406-4dbe-be09-77ed3b9a66fd@github.com> Message-ID: <28rS8Vqoyrc09J9cdn1tWXByIZUV9GL-_Hjcn3bMLBk=.ff9e5545-9f30-42cd-b2e1-56954bbdfbf2@github.com> On Thu, 24 Jul 2025 10:29:15 GMT, Galder Zamarre?o wrote: > I've added support to vectorize `MoveD2L`, `MoveL2D`, `MoveF2I` and `MoveI2F` nodes. The implementation follows a similar pattern to what is done with conversion (`Conv*`) nodes. The tests in `TestCompatibleUseDefTypeSize` have been updated with the new expectations. > > Also added a JMH benchmark which measures throughput (the higher the number the better) for methods that exercise these nodes. On darwin/aarch64 it shows: > > > Benchmark (seed) (size) Mode Cnt Base Patch Units Diff > VectorBitConversion.doubleToLongBits 0 2048 thrpt 8 1168.782 1157.717 ops/ms -1% > VectorBitConversion.doubleToRawLongBits 0 2048 thrpt 8 3999.387 7353.936 ops/ms +83% > VectorBitConversion.floatToIntBits 0 2048 thrpt 8 1200.338 1188.206 ops/ms -1% > VectorBitConversion.floatToRawIntBits 0 2048 thrpt 8 4058.248 14792.474 ops/ms +264% > VectorBitConversion.intBitsToFloat 0 2048 thrpt 8 3050.313 14984.246 ops/ms +391% > VectorBitConversion.longBitsToDouble 0 2048 thrpt 8 3022.691 7379.360 ops/ms +144% > > > The improvements observed are a result of vectorization. The lack of vectorization in `doubleToLongBits` and `floatToIntBits` demonstrates that these changes do not affect their performance. These methods do not vectorize because of flow control. > > I've run the tier1-3 tests on linux/aarch64 and didn't observe any regressions. This pull request has now been integrated. Changeset: 8c4090c2 Author: Galder Zamarre?o Committer: Roland Westrelin URL: https://git.openjdk.org/jdk/commit/8c4090c2cfa00f9c3550669a0726a785b30ac1d5 Stats: 67 lines in 4 files changed: 57 ins; 4 del; 6 mod 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F Reviewed-by: epeter, qamai ------------- PR: https://git.openjdk.org/jdk/pull/26457 From alanb at openjdk.org Wed Sep 3 06:45:43 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Sep 2025 06:45:43 GMT Subject: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v4] In-Reply-To: References: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> Message-ID: <4qSeUzMrZUQfmItUEHAwVOu2nfxHSJpau7cFakrsggI=.d8064939-0b3a-40e1-bf7b-1bca955f07d5@github.com> On Tue, 2 Sep 2025 20:23:26 GMT, Brian Burkhalter wrote: >> Attempt to improve the verbiage of the `java.io.File` specification to make it clearer whether a given method operates only on an abstract pathname or on the actual file system entry it denotes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8366102: "denoted by" -> "located by" > That definitely is more precise to me. So changed in [6d3587e](https://github.com/openjdk/jdk/commit/6d3587e9c13e50b883ead56bf600348fac5d9cd3). Good, this looks much better. Do you mind checking the remaining usages of "denotes" in the method descriptions of methods that access the file system, specifically getCanonicalPath, length, delete, list/listFiles, renameTo, and createTempFile? If we change these to use "locates" then I think the wording will be clear throughout. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27006#issuecomment-3247890783 From coffeys at openjdk.org Wed Sep 3 07:34:42 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 3 Sep 2025 07:34:42 GMT Subject: RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5> In-Reply-To: <-ncJDkarXFF1QXX5Q8JL6Zw4FRy6r2Sq-Ru1yPhLH6Q=.8adde0f5-abe3-4439-aac4-46db36698a39@github.com> References: <-ncJDkarXFF1QXX5Q8JL6Zw4FRy6r2Sq-Ru1yPhLH6Q=.8adde0f5-abe3-4439-aac4-46db36698a39@github.com> Message-ID: On Wed, 3 Sep 2025 05:51:03 GMT, Jaikiran Pai wrote: > The `java.util.zip.ZipFile` maintains an internal cache for an underlying ZIP file to read its CEN just once to try and avoid reading it every time a `ZipFile` instance is created. One internal implementation detail of that cache is that it has the ability to detect an update to the underlying ZIP file so that when a subsequent instance of `ZipFile` is created then it won't re-use an already cached CEN but instead will re-read the CEN (and cache it) afresh. To detect the updates to the ZIP file, it uses the last modified time of the file; and last modified timestamps have a granularity. I'm still thinking the inner ZIpFile logic might have an issue if it can't detect an update to a ZipFile. The inner Source class will return an incorrect mapping and CEN calculation if a new Source isn't created. The test fails since the internal cache doesn't increment by 1, i.e. a new entry wasn't added to HashMap after ZIpFile was updated. An obsolete key is returned since the Key class `hashcode` method doesn't detect a difference due to the coarse nature of the FS timestamps public int hashCode() { long t = charset.hashCode(); t += attrs.lastModifiedTime().toMillis(); Object fk = attrs.fileKey(); return Long.hashCode(t) + (fk != null ? fk.hashCode() : file.hashCode()); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3248039490 From pminborg at openjdk.org Wed Sep 3 08:31:49 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 3 Sep 2025 08:31:49 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 09:43:23 GMT, Amit Kumar wrote: >> Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 >> >> These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): >> >> java/foreign/TestFill.java >> java/foreign/TestSegments.java >> java/foreign/TestSegmentBulkOperationsContentHash.java >> java/foreign/TestStringEncoding.java >> java/foreign/TestVarArgs.java >> >> >> >> ```java >> // Always allocate at least some memory so that zero-length segments have distinct >> // non-zero addresses. >> alignedSize = Math.max(1, alignedSize); >> >> >> Here minimum-allocated size will be 1, which is incorrect because >> >> >> private static void initNativeMemory(long address, long byteSize) { >> for (long i = 0; i < byteSize; i += Long.BYTES) { >> UNSAFE.putLongUnaligned(null, address + i, 0); >> } >> } >> >> `initNativeMemory()` is going to write Long. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > update The new changes look good. Thanks for fixing this issue. Please update the title of the PR so we can integrate this one. ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27027#pullrequestreview-3179528509 From jpai at openjdk.org Wed Sep 3 08:55:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Sep 2025 08:55:48 GMT Subject: RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5> In-Reply-To: References: <-ncJDkarXFF1QXX5Q8JL6Zw4FRy6r2Sq-Ru1yPhLH6Q=.8adde0f5-abe3-4439-aac4-46db36698a39@github.com> Message-ID: On Wed, 3 Sep 2025 07:32:19 GMT, Sean Coffey wrote: > I'm still thinking the inner ZIpFile logic might have an issue if it can't detect an update to a ZipFile. The inner Source class will return an incorrect mapping and CEN calculation if a new Source isn't created. It's true that until a ZIP file update is detected then instances of `ZipFile` (including the newly created one) will continue to use the old cached CEN data and yes that's an inherent issue with the caching of this data. But that's not a new one and from what I know it has been there since we moved the ZIP handling code to java (and perhaps even before that https://bugs.openjdk.org/browse/JDK-8145260). However, i can't think of a simple way to avoid such situations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3248304828 From asotona at openjdk.org Wed Sep 3 09:01:46 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 3 Sep 2025 09:01:46 GMT Subject: RFR: 8361635: Missing List length validation in the Class-File API [v3] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 14:57:01 GMT, Chen Liang wrote: >> The `class` file format often only stores lists up to 65535 in size because size is encoded as a u2. Currently, we truncate the list size and write all contents, creating malformed `class` files. Almost all scenarios where such oversized lists are created can be considered an error; we should eagerly reject lists that would never be encodable in the `class` file format when users construct model objects. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-list-sizes > - Link to u1/u2 > - Merge branch 'fix/cf-u2-validation' into fix/cf-list-sizes > - Another missed spot > - Typo, thanks Adam > - Missed one link > - New u2 central info stage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-u2-validation > - Package-level information > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-list-sizes > - ... and 11 more: https://git.openjdk.org/jdk/compare/ae960772...0e74a9a5 Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26252#pullrequestreview-3179666687 From alan.bateman at oracle.com Wed Sep 3 09:09:26 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 3 Sep 2025 10:09:26 +0100 Subject: MethodHandles.lookup errors where publicLookup is ok In-Reply-To: References: <76593135-89db-41ef-a493-5dd60e873e09@oracle.com> Message-ID: <6bb9f1ec-4c1b-4893-8751-0c72da940877@oracle.com> On 02/09/2025 20:36, Charles Oliver Nutter wrote: > > However... why doesn't `findVirtual()` request read access to the > given class's module before erroring? Presumably this is what the > reflected call and the `publicLookup()` logic does. Worst case, it > would raise an error because it cannot gain such access. If there's > another down side to requesting read access automatically when read > access is clearly required, I'd like to know about it... because now I > have to do it manually anyway. Method handles are aligned with bytecode behavior, this includes access checks in the MH factory methods. If you were to inject code into module org.jruby.dist with a reference to a class in module X then any attempt in org.jruby.dist to access a class in module X would fail with IllegalAccessError. org.jruby.dist's module does not declare "requires X" and so org.jruby.dist does not read X. Lookup.publicLookup is the minimally trusted lookup to create method handles to public fields and methods. This necessitated the addition of the UNCONDITIONAL access mode even though it doesn't correspond to a modifier in the access flags. It means that the access check done with the publicLookup is closer to what you see with core reflection (where readability is assumed) rather than bytecode. This may seem complicated but it's not something that most developers will ever need to deal with directly. > > As regards diagnosing this then I think we need improve the > IllegalAccessExceptions exception messages. A lot of effort went > into JDK 9 to ensure that the IAE thrown in the core reflection > access spelled out the reason why the access check failed. Most > reflection based frameworks used core reflection at the time. We > should have put more effort into the having the IAE exception > messages in j.l.invoke as "is not accessible" makes it hard to > diagnose. > > > Raising an error saying it "is not accessible" is also rather > misleading when it actually **is** accessible It's not accessible from code in module org.jruby.dist so not accessible with the Lookup obtained from lookup(). That said, we need to improve the IAE exception messages. A lot of effort went into exception messages thrown by setAccessible/Method.invoke/Field.xxx where as the IAE exception messages thrown by the MH factory methods are less helpful. BTW: Your first message has "symbolic reference class is not accessible: class jdk.proxy4.$Proxy49" which suggests that the JRuby code may be attempting the findVirtual for the method in the proxy implementation class rather than the method in the interface class. You might to check that. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at openjdk.org Wed Sep 3 09:18:46 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 3 Sep 2025 09:18:46 GMT Subject: RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5> In-Reply-To: References: <-ncJDkarXFF1QXX5Q8JL6Zw4FRy6r2Sq-Ru1yPhLH6Q=.8adde0f5-abe3-4439-aac4-46db36698a39@github.com> Message-ID: On Wed, 3 Sep 2025 08:53:22 GMT, Jaikiran Pai wrote: > However, i can't think of a simple way to avoid such situations. Adding file size into the mix should be cheap while still improving the heuristics on file systems with course time granularity. This will also help cases where the last modified date is explicitly set by the system and cannot be trusted and on file systems which don't support last modification date at all and always return something like the epoch. Adding file size would likely aviod this test failure, however it's maybe better to consider in a separate change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3248402569 From rgiulietti at openjdk.org Wed Sep 3 09:28:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 3 Sep 2025 09:28:51 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 19:00:23 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Revision changes I think the PR is in a good state. src/java.base/share/classes/java/math/MutableBigInteger.java line 2040: > 2038: } else { > 2039: // Discard wrong integer bits from the initial estimate > 2040: // The radicand has Math.getExponent(rad)+1 integer bits, but only Suggestion: // The reduced radicand rad has Math.getExponent(rad)+1 integer bits, but only src/java.base/share/classes/java/math/MutableBigInteger.java line 2059: > 2057: /* The Newton's recurrence roughly duplicates the correct bits at each iteration. > 2058: * Instead of shifting the approximate root into the original range right now, > 2059: * we only duplicate its bit length and then refine it with Newton's recurrence, Suggestion: /* The Newton's recurrence roughly doubles the correct bits at each iteration. * Instead of shifting the approximate root into the original range right now, * we only double its bit length and then refine it with Newton's recurrence, src/java.base/share/classes/java/math/MutableBigInteger.java line 2060: > 2058: * Instead of shifting the approximate root into the original range right now, > 2059: * we only duplicate its bit length and then refine it with Newton's recurrence, > 2060: * using a congruent shifted radicand, in order to avoid computing and Maybe clarify what "congruent" means here ------------- PR Review: https://git.openjdk.org/jdk/pull/24898#pullrequestreview-3179775832 PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2318360217 PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2318360557 PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2318360386 From duke at openjdk.org Wed Sep 3 09:33:43 2025 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Sep 2025 09:33:43 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v3] In-Reply-To: References: Message-ID: <-9xZMei8RG9SNQZppoVG6F9_SYh0awM4Y5gbAtVdtKo=.8046cba6-2c2a-4194-8747-fe4a852c32b9@github.com> On Tue, 2 Sep 2025 21:12:01 GMT, Justin Lu wrote: >> Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: >> >> changed tzid to more readable timeZoneID > > Thanks for the change. I ran the manual test and can confirm that the zone ID now updates in the window when the platform tz is changed. > Nit: Copyright year can be updated. @justin-curtis-lu I have updated the Copyright year, please review and approve. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27043#issuecomment-3248460755 From rgiulietti at openjdk.org Wed Sep 3 09:42:49 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 3 Sep 2025 09:42:49 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:24:32 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Revision changes > > src/java.base/share/classes/java/math/MutableBigInteger.java line 2059: > >> 2057: /* The Newton's recurrence roughly duplicates the correct bits at each iteration. >> 2058: * Instead of shifting the approximate root into the original range right now, >> 2059: * we only duplicate its bit length and then refine it with Newton's recurrence, > > Suggestion: > > /* The Newton's recurrence roughly doubles the correct bits at each iteration. > * Instead of shifting the approximate root into the original range right now, > * we only double its bit length and then refine it with Newton's recurrence, In `BigIntegerTest`, the methods related to nth-root do not seem to be invoked. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2318395246 From rgiulietti at openjdk.org Wed Sep 3 09:42:50 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 3 Sep 2025 09:42:50 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: <_y9vww6S6hl4ja6APKxGhM7uNp7U-kjpGgeMCF2qQ5w=.6bb5819f-3581-4d30-9364-0790e7ff1176@github.com> On Wed, 3 Sep 2025 09:38:19 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 2059: >> >>> 2057: /* The Newton's recurrence roughly duplicates the correct bits at each iteration. >>> 2058: * Instead of shifting the approximate root into the original range right now, >>> 2059: * we only duplicate its bit length and then refine it with Newton's recurrence, >> >> Suggestion: >> >> /* The Newton's recurrence roughly doubles the correct bits at each iteration. >> * Instead of shifting the approximate root into the original range right now, >> * we only double its bit length and then refine it with Newton's recurrence, > > In `BigIntegerTest`, the methods related to nth-root do not seem to be invoked. If it makes your life easier, you could extract just your tests and create a new JUnit based test class. Up to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2318400214 From duke at openjdk.org Wed Sep 3 09:49:58 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 3 Sep 2025 09:49:58 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:24:28 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Revision changes > > src/java.base/share/classes/java/math/MutableBigInteger.java line 2060: > >> 2058: * Instead of shifting the approximate root into the original range right now, >> 2059: * we only duplicate its bit length and then refine it with Newton's recurrence, >> 2060: * using a congruent shifted radicand, in order to avoid computing and > > Maybe clarify what "congruent" means here The way the radicand is determined is specified in the same comment below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2318418244 From duke at openjdk.org Wed Sep 3 09:55:26 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 3 Sep 2025 09:55:26 GMT Subject: RFR: 8077587: BigInteger Roots [v79] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Raffaello Giulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/fbe7a427..7237170d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=78 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=77-78 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From rgiulietti at openjdk.org Wed Sep 3 10:00:55 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 3 Sep 2025 10:00:55 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:47:16 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 2060: >> >>> 2058: * Instead of shifting the approximate root into the original range right now, >>> 2059: * we only duplicate its bit length and then refine it with Newton's recurrence, >>> 2060: * using a congruent shifted radicand, in order to avoid computing and >> >> Maybe clarify what "congruent" means here > > The way the radicand is determined is specified in the same comment below. What I mean is that "congruent" usually has a specific mathematical meaning, which is not what is meant here, IIUC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2318445423 From duke at openjdk.org Wed Sep 3 10:04:51 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 3 Sep 2025 10:04:51 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:57:53 GMT, Raffaello Giulietti wrote: >> The way the radicand is determined is specified in the same comment below. > > What I mean is that "congruent" usually has a specific mathematical meaning, which is not what is meant here, IIUC. Then maybe "suitable" is better than "congruent"... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2318455524 From duke at openjdk.org Wed Sep 3 10:12:54 2025 From: duke at openjdk.org (erifan) Date: Wed, 3 Sep 2025 10:12:54 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v7] In-Reply-To: <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com> References: <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com> Message-ID: On Thu, 5 Jun 2025 11:05:48 GMT, Emanuel Peter wrote: >>> > FYI: `BoolTest::negate` already does what you want: `mask negate( ) const { return mask(_test^4); }` I think you should use that instead :) >>> >>> Indeed, I hadn't noticed that, thank you. >> >> Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function. > >> Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function. > > I see. Ok. Hmm. I still think that the logic should be in `BoolTest`, because that is where the exact implementation of the enum values is. In that context it is easier to see why `^4` does the negation. And imagine we were ever to change the enum values, then it would be harder to find your code and fix it. > > Maybe it could be called `BoolTest::negate_mask(mast btm)` and explain in a comment that both signed and unsigned is supported. Hi @eme64 @theRealAph @XiaohongGong @fg1417 @shqking , could you help take a look at this PR, thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-3248596662 From ayang at openjdk.org Wed Sep 3 10:14:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 10:14:49 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v12] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 06:45:25 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java > > change overflow check Two minor comments/suggestions. Looks good otherwise. src/java.base/share/classes/java/lang/Class.java line 226: > 224: private static final int ENUM = 0x00004000; > 225: private static final int SYNTHETIC = 0x00001000; > 226: private static final int JAVA_CLASSNAME_MAX_LEN = 65535; Do we need a comment explaining where this magic number comes from? src/java.base/share/classes/java/lang/Class.java line 4170: > 4168: // The check utfLen >= nameLen ensures we don't incorrectly return true in case of int overflow. > 4169: int utfLen = ModifiedUtf.utfLen(name, 0); > 4170: return utfLen <= JAVA_CLASSNAME_MAX_LEN && utfLen >= nameLen; I would probably use early-return for the overflow case, sth like the following, to separate the normal logic from error-handling logic. if (utfLen < nameLen) { // overflowing... return false; } return utfLen <= JAVA_CLASSNAME_MAX_LEN; ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26802#pullrequestreview-3179936966 PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2318477446 PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2318477926 From duke at openjdk.org Wed Sep 3 10:52:06 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 3 Sep 2025 10:52:06 GMT Subject: RFR: 8077587: BigInteger Roots [v80] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Reduce max size of input test to spend less time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/7237170d..a58784d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=79 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=78-79 Stats: 7 lines in 2 files changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From alanb at openjdk.org Wed Sep 3 11:36:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Sep 2025 11:36:46 GMT Subject: RFR: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 21:21:04 GMT, Justin Lu wrote: >> This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. >> >> Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > public API is too broad Thanks for adding a test, that will help catch any further regressions when changing this code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27008#issuecomment-3248859821 From alanb at openjdk.org Wed Sep 3 11:37:43 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Sep 2025 11:37:43 GMT Subject: RFR: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 [v2] In-Reply-To: References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> Message-ID: On Tue, 2 Sep 2025 22:15:29 GMT, Justin Lu wrote: >> This PR addresses a JCK test failure of an unexpected SIOOBE during DecimalFormat parsing. During the char by char comparison in `matchAffix`, the minimum of the length of the parsed String and the PP index + affix length are iterated on. The parse position index needs to be checked to not be negative to ensure that we do not index the String below 0. Taking the minimum of those two previously mentioned values already guarantees that we do not index the String above the length. > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Missing the bug ID in the new test > - Adding additional tests and moving tests to PositionTest Thanks for expanding the coverage of the existing tests. That will help catch any regressions when changing the parsing code in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27014#issuecomment-3248863177 From jpai at openjdk.org Wed Sep 3 11:44:40 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Sep 2025 11:44:40 GMT Subject: RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5> In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 14:33:03 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses a failure in `test/jdk/java/util/zip/ZipFile/ZipSourceCache.java` test? > > As noted in the description of https://bugs.openjdk.org/browse/JDK-8366439, this test fails if the underlying file system's timestamp granularity doesn't allow for the last modified timestamp to increase when the test's ZIP file is updated with newer content. > > The change in this PR updates the test to first check that the last modified timestamp has increased on the ZIP file that was updated, before running the rest of the test assertions. The test continues to pass in our CI with this change. Hello Eirik, > Adding file size into the mix should be cheap while still improving the heuristics on file systems with course time granularity. This will also help cases where the last modified date is explicitly set by the system and cannot be trusted and on file systems which don't support last modification date at all and always return something like the epoch. Adding file size as another component to the cache's key sounds reasonable and can reduce the chances of not detecting an update to the ZIP file contents. I'll wait a day or two to hear from others before deciding if we should go ahead with that idea. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3248882067 From pavel.rappo at gmail.com Wed Sep 3 11:49:16 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 3 Sep 2025 12:49:16 +0100 Subject: Duration.MAX_VALUE Message-ID: Couldn't recall or quickly find if this was asked before. I come across this quite often: there doesn?t seem to be a readily available maximum value for java.time.Duration -- a value that represents the longest possible duration. I assume there are plenty of homegrown constants out in the wild addressing this. Don?t get me wrong: it?s not hard to create one. The issue, in my experience, is that it takes time and sometimes experimentation. Unless one reads the Javadoc carefully, it?s not obvious that the maximum duration can be constructed as follows: Duration.of(Long.MAX_VALUE, 999_999_999); Naturally, one might first try using IDE autocomplete. For example, creating a Duration from Long.MAX_VALUE of a large unit -- millennia, centuries, decades, etc. -- only to run into ArithmeticException. Only when reaching seconds does it finally work: Duration.ofSeconds(Long.MAX_VALUE); or Duration.of(Long.MAX_VALUE, ChronoUnit.SECONDS); Of course, there?s no practical difference between Duration.of(Long.MAX_VALUE, 999_999_999) and Duration.ofSeconds(Long.MAX_VALUE). We?re talking about durations on the order of 292 billion years, after all. The exact value isn?t the problem. The problem is that the values are inconsistent, and arriving to them is error-prone. Adding a constant to java.time.Duration would simplify things. -Pavel From dclarke at openjdk.org Wed Sep 3 12:11:51 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Wed, 3 Sep 2025 12:11:51 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> Message-ID: On Thu, 28 Aug 2025 08:51:14 GMT, Darragh Clarke wrote: >> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. >> >> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. >> >> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. > > Darragh Clarke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - fixed copyright header > - merged master into branch > - moved repeating code into own method > - implementing feedback, adding missing errno checks, cleanup > - feedback > - general cleanup > - small refactoring > - Performance > - implementing feedback > - removed unrelated change > - ... and 2 more: https://git.openjdk.org/jdk/compare/fbe3c71c...cc5f558a So I double checked the changes made there and wrote this up, I can make it more precise or change wording if its going to be attached to a file. Package info currently contains the script used to generate the code **Common changes:** - utility methods and constant values got moved into FFMUtils, this is to cut down on duplicated code as more FFM code gets added - kqueue_h and kevent both get updated to reference FFMUtils **kqueue_h specific changes:** - Errno handling had to be added, this involved adding the `ADAPTED` method handles as well as editing the `HANDLE` methodhandle to add `Linker.Option.captureCallState(ERRNO_NAME));` - Removing some unused generated objects such as `static final Arena LIBRARY_ARENA = Arena.ofAuto();` - added `private static final String ERRNO_NAME = "errno?;` ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3248980788 From eirbjo at openjdk.org Wed Sep 3 12:24:41 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 3 Sep 2025 12:24:41 GMT Subject: RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5> In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 14:33:03 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses a failure in `test/jdk/java/util/zip/ZipFile/ZipSourceCache.java` test? > > As noted in the description of https://bugs.openjdk.org/browse/JDK-8366439, this test fails if the underlying file system's timestamp granularity doesn't allow for the last modified timestamp to increase when the test's ZIP file is updated with newer content. > > The change in this PR updates the test to first check that the last modified timestamp has increased on the ZIP file that was updated, before running the rest of the test assertions. The test continues to pass in our CI with this change. A related observation: It seems dubious that `Key::hashCode` calls `toMillis` on the `FileTime` object, while `Key::equals` simply delegates to `FileTime:equals`: // hashCode: t += attrs.lastModifiedTime().toMillis(); vs. // equals: !attrs.lastModifiedTime().equals(key.attrs.lastModifiedTime()) While this conversion to millisecond precision does not break the hashCode/equals contract, I'm wondering if it would be simpler and more clear to instead delegate to `FileTime::hashCode`: t += attrs.lastModifiedTime().hashCode(); ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3249022632 From lkorinth at openjdk.org Wed Sep 3 12:39:00 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 3 Sep 2025 12:39:00 GMT Subject: Integrated: 8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java Message-ID: Just need the old timeout value result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-26+14-1410\windows-x64-debug.jdk\jdk-26\fastdebug\bin\java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 178895ms). ------------- Commit messages: - 8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java Changes: https://git.openjdk.org/jdk/pull/27070/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27070&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366803 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27070.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27070/head:pull/27070 PR: https://git.openjdk.org/jdk/pull/27070 From stefank at openjdk.org Wed Sep 3 12:39:00 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 12:39:00 GMT Subject: Integrated: 8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 12:32:17 GMT, Leo Korinth wrote: > Just need the old timeout value > > result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-26+14-1410\windows-x64-debug.jdk\jdk-26\fastdebug\bin\java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 178895ms). Marked as reviewed by stefank (Reviewer). This can be considered "trivial". ------------- PR Review: https://git.openjdk.org/jdk/pull/27070#pullrequestreview-3180433547 PR Comment: https://git.openjdk.org/jdk/pull/27070#issuecomment-3249065789 From lkorinth at openjdk.org Wed Sep 3 12:39:00 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 3 Sep 2025 12:39:00 GMT Subject: Integrated: 8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 12:32:17 GMT, Leo Korinth wrote: > Just need the old timeout value > > result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-26+14-1410\windows-x64-debug.jdk\jdk-26\fastdebug\bin\java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 178895ms). Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27070#issuecomment-3249070093 From lkorinth at openjdk.org Wed Sep 3 12:39:00 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 3 Sep 2025 12:39:00 GMT Subject: Integrated: 8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 12:32:17 GMT, Leo Korinth wrote: > Just need the old timeout value > > result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-26+14-1410\windows-x64-debug.jdk\jdk-26\fastdebug\bin\java' timed out (timeout set to 120000ms, elapsed time including timeout handling was 178895ms). This pull request has now been integrated. Changeset: 3b2f3e53 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/3b2f3e53d7f27653c3d4608b141aed6a84829aa8 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java Reviewed-by: stefank ------------- PR: https://git.openjdk.org/jdk/pull/27070 From stefank at openjdk.org Wed Sep 3 13:53:52 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 13:53:52 GMT Subject: RFR: 8366298: FDLeakTest sometimes takes minutes to complete on Linux [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 08:03:27 GMT, Stefan Karlsson wrote: >> While investigating [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on Linux. >> >> The reason is that the test performs a `fcntl` call for each and every potential file descriptor number. This can be a large number of calls and sometimes results in minutes-long test executions. >> >> I propose that we fix this by limiting the max number of open file descriptors. This lowers the test execution time to about 1 second. >> >> The test has two processes. One that executes the libFDLeaker.c code below as an agent in the test JVM, then it forks into a exeFDLeakTester.c, which reads the property `int max_fd = (int)sysconf(_SC_OPEN_MAX);`. The setting of `RLIMIT_NOFILE` to `100` lowers `max_fd` to `100`. I've verified this on both Linux and on macOS. >> >> I've run the test manually on Linux and macOS and verified that it runs faster. I've also run this through tier1. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Remove jtreg timeouts > - Merge remote-tracking branch 'upstream/master' into 8366298_fdleaktest > - Add error logging > - 8366298: FDLeakTest sometimes takes minutes to complete on Linux Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26979#issuecomment-3248048122 From stuefe at openjdk.org Wed Sep 3 13:53:52 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 3 Sep 2025 13:53:52 GMT Subject: RFR: 8366298: FDLeakTest sometimes takes minutes to complete on Linux [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 08:03:27 GMT, Stefan Karlsson wrote: >> While investigating [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on Linux. >> >> The reason is that the test performs a `fcntl` call for each and every potential file descriptor number. This can be a large number of calls and sometimes results in minutes-long test executions. >> >> I propose that we fix this by limiting the max number of open file descriptors. This lowers the test execution time to about 1 second. >> >> The test has two processes. One that executes the libFDLeaker.c code below as an agent in the test JVM, then it forks into a exeFDLeakTester.c, which reads the property `int max_fd = (int)sysconf(_SC_OPEN_MAX);`. The setting of `RLIMIT_NOFILE` to `100` lowers `max_fd` to `100`. I've verified this on both Linux and on macOS. >> >> I've run the test manually on Linux and macOS and verified that it runs faster. I've also run this through tier1. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Remove jtreg timeouts > - Merge remote-tracking branch 'upstream/master' into 8366298_fdleaktest > - Add error logging > - 8366298: FDLeakTest sometimes takes minutes to complete on Linux Hmm... skara stuck? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26979#issuecomment-3249347313 From stefank at openjdk.org Wed Sep 3 13:53:53 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 13:53:53 GMT Subject: Integrated: 8366298: FDLeakTest sometimes takes minutes to complete on Linux In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 07:46:36 GMT, Stefan Karlsson wrote: > While investigating [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on Linux. > > The reason is that the test performs a `fcntl` call for each and every potential file descriptor number. This can be a large number of calls and sometimes results in minutes-long test executions. > > I propose that we fix this by limiting the max number of open file descriptors. This lowers the test execution time to about 1 second. > > The test has two processes. One that executes the libFDLeaker.c code below as an agent in the test JVM, then it forks into a exeFDLeakTester.c, which reads the property `int max_fd = (int)sysconf(_SC_OPEN_MAX);`. The setting of `RLIMIT_NOFILE` to `100` lowers `max_fd` to `100`. I've verified this on both Linux and on macOS. > > I've run the test manually on Linux and macOS and verified that it runs faster. I've also run this through tier1. This pull request has now been integrated. Changeset: 3abaa836 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/3abaa83610efb5c8e9b86c6f895d6b58d21e1fa2 Stats: 42 lines in 2 files changed: 39 ins; 0 del; 3 mod 8366298: FDLeakTest sometimes takes minutes to complete on Linux Reviewed-by: lkorinth, rriggs, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/26979 From chen.l.liang at oracle.com Wed Sep 3 14:48:06 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Wed, 3 Sep 2025 14:48:06 +0000 Subject: Excessive copying of Collection.toArray() In-Reply-To: References: Message-ID: Hello Shaun, note that the optimizing compiler in the JVM (C2) can likely eliminate 3 of the 4 copies, all except 1 (which is not a defensive copy). 2 could be eliminated when escape analysis finds the result of HashSet.toArray does not escape beyond the toArray method, so subsequent clone is elided. 4 could be eliminated when EA concludes the result of ArrayList.toArray does not escape beyond the toArray method, so subsequent clone is elided. 3 could be eliminated when EA concludes the `ArrayList` does not escape beyond the sortedImmutableList method. This one is harder for compilers than the previous two. Unlike the trusting by class loader, the escape analysis trusting can apply to user structures. There have been previous attempts to reduce copying here and there, but they do suffer from the problems you have described. See https://github.com/openjdk/jdk/pull/12212. Regards, Chen Liang ________________________________ From: core-libs-dev on behalf of Shaun Spiller Sent: Tuesday, September 2, 2025 1:19 PM To: core-libs-dev at openjdk.org Subject: Excessive copying of Collection.toArray() Hello! Please consider the following real utility method I have: /** * Returns an immutable list via {@link List#of} that is the * sorted content of the collection. */ public static @NonNull List sortedImmutableList( @NonNull Collection col, @Nullable Comparator comparator) { ArrayList list = new ArrayList<>(col); list.sort(comparator); return List.copyOf(list); } Quiz question: Assume this method is invoked with a large HashSet as its collection argument. How many ARRAY copies of the collection are created by this method? Clearly there must be at least one for the result, held internally in the immutable list. Any others? (Scroll for the answer.) . . . . . . . . . . . . . . . . . . . I was surprised to realize the answer is four: 1. ArrayList calls toArray() on the HashSet. 2. ArrayList defensively copies the array to assign to its internal elementData field, because it doesn't trust HashSet. 3. List.copyOf calls toArray() on the ArrayList. 4. List.of defensively copies the array to assign to its internal elements field, because it doesn't trust ArrayList. It is quite possible to rewrite my particular utility method with a raw array instead of ArrayList, to eliminate 2 array copies, but this requires an icky unchecked cast, and by rights is the kind of thing that shouldn't be necessary anyway. ----- In general, this kind of excessive defensive copying is going on ALL THE TIME. The underlying nuisance is that a subclass of Collection could potentially override toArray() to keep a reference to the returned array and make mischief with it. (Also, for ArrayList, it would be a problem if the returned array were a subclass of Object[].) I did a search thru the JDK and found a slew of cases where code calls Collection.toArray() and then has to worry about defensively copying it -- or trying to avoid defensively copying it: - java.util.List.copyOf(Collection) -- avoids copying an existing List.of/copyOf list, but for any other collection it calls toArray() and then defensively copies it again - java.util.ArrayList(Collection) -- constructor has a special check `if (collection.getClass() == ArrayList.class)`, in which case it skips the defensive copy and trusts the result of toArray(), but it does not trust any other collection - java.util.Vector(Collection) -- constructor has the same optimization trick as ArrayList, where it trusts ArrayList, but creates a defensive copy for any other collection. Vector doesn't even trust itself! - java.util.PriorityQueue.initElementsFromCollection(Collection) -- has optimization for ArrayList, but no other collection - java.util.concurrent.PriorityBlockingQueue(Collection) -- has optimization for ArrayList, but no other collection - java.util.concurrent.CopyOnWriteArrayList(Collection) -- has optimizations for ArrayList and CopyOnWriteArrayList, but no other collection. - java.util.concurrent.CopyOnWriteArrayList.addAllAbsent(Collection) -- has optimization for ArrayList but no other collection. - java.util.stream.Collectors.toUnmodifiableList() -- this avoids an excess copy, but does so in a very complicated way - sun.awt.util.IdentityArrayList(Collection) -- this appears to be an old copy-paste of ArrayList except with identity indexOf; like pre-2020 ArrayList, it blindly trusts that `col.toArray()` returns a new array, although based on this class's extremely limited use there is no manifestable bug. - java.lang.invoke.MethodHandles.dropArguments/dropArgumentsToMatch -- these call `list.toArray()` and then clone the array unconditionally - java.time.zone.ZoneRules.of(...) -- calls `lastRules.toArray()` and then clones the array unconditionally ----- I would suggest that there should be an internal utility method for use in all these cases, something like: public static Object[] safeToArray(Collection c) { Object[] a = c.toArray(); if (!isTrusted(c)) { a = Arrays.copyOf(a, a.length, Object[].class); } return a; } The delicate issue then is: what is the correct design of "isTrusted"? The check must be fast, and not spoofable by classes outside the JDK. My first thought was to detect that the class is loaded by the bootstrap class loader: static boolean isTrusted(Collection c) { return c.getClass().getClassLoader() == null; } However, I now realize this is unwise because it would shift the burden of trust into **every** Collection class in the JDK, instead of into the classes that actually care about the result. For example, Collections.UnmodifiableCollection.toArray() simply returns the result of its internal `col.toArray()`, which immediately carves a hole the size of a bus thru the check. Perhaps better would be for classes to explicitly opt-in and say "Yes, I promise that my toArray() method is safe". Would a package-private marker interface work for this? I am not sure. Anyway, the point is that classes within the JDK should not need to create so many defensive copies of each other. Note that this is becoming more of an issue now that List.of is becoming a popular "go-to" list for many situations where ArrayList would traditionally have been used. The "only trust ArrayList" pattern was never ideal and is starting to age. This is my first post here so I apologize for oversights in formatting or etiquette. Thanks for reading. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at openjdk.org Wed Sep 3 15:03:45 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Wed, 3 Sep 2025 15:03:45 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: <5134m5ttzdbgrrPBJLbQLC9TsZ8-MyIg9Ky1Js2pMZ4=.f44a3a5d-1c75-4b76-98a8-3344cac98e2d@github.com> References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> <5134m5ttzdbgrrPBJLbQLC9TsZ8-MyIg9Ky1Js2pMZ4=.f44a3a5d-1c75-4b76-98a8-3344cac98e2d@github.com> Message-ID: On Sat, 30 Aug 2025 15:05:24 GMT, Alan Bateman wrote: >> We could use indices/offsets directly in the methods that receive the slices from this method. > > `getDescriptor(MemorySegment keventArray, int index)` and `getFilter(MemorySegment keventArray, int index)` would work for the use-sites. > > The other thing here is that a fd is an int rather than a long. The re-implemented KQueue should pick ident or fd (the common usage). Right now register takes an int fd, where the modified getDescriptor is actually returning the 64-bit ident. So on my local branch I've address all the comments except the two in this thread, So for using the indices directly what would that look like? would we remove getEvent and instead pass the `MemorySegment` and whatever indices we want to access directly to getDescriptor/getFilter? As for fd/ident, I think that's interesting, the reason for getDescriptor using long ident is because that's what jextract generated for it (from `uintptr_t` specifically), I see that in mainline today it's just the simpler call of ` return unsafe.getInt(address + OFFSET_IDENT);` I could try just replicating the existing code instead of using the generated method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2319266899 From naoto at openjdk.org Wed Sep 3 15:22:23 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 15:22:23 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v2] In-Reply-To: References: Message-ID: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Use Objects.requireNonNull() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27060/files - new: https://git.openjdk.org/jdk/pull/27060/files/5007b81e..7b3d4e00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27060&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27060&range=00-01 Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27060/head:pull/27060 PR: https://git.openjdk.org/jdk/pull/27060 From alanb at openjdk.org Wed Sep 3 15:22:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Sep 2025 15:22:52 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> <5134m5ttzdbgrrPBJLbQLC9TsZ8-MyIg9Ky1Js2pMZ4=.f44a3a5d-1c75-4b76-98a8-3344cac98e2d@github.com> Message-ID: On Wed, 3 Sep 2025 15:00:22 GMT, Darragh Clarke wrote: > I could try just replicating the existing code instead of using the generated method? We always use the ident as an fd so don't use the full width. It doesn't matter if KQueue uses int fd or long ident in the API that it exposes but I'd prefer not to have a mix of both, at least not with good naming to avoid mis-use. If you want a preference then expose just the narrow fd form would work best the use-sites. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2319323168 From naoto at openjdk.org Wed Sep 3 15:23:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 15:23:44 GMT Subject: RFR: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected [v5] In-Reply-To: References: Message-ID: <4mXSGoIkRXmbPtv38taBT4ZT89b46s3IxAq8aAQAJVQ=.b271401a-e04b-4720-9023-dabf2baa2a83@github.com> On Wed, 3 Sep 2025 06:13:17 GMT, Vanitha B P wrote: >> Problem Statements: >> 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. >> 2. ZoneID was not displaying in the window as it is displaying in the lower releases. >> >> Test Results: >> jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java >> >> Passed: java/util/TimeZone/DefaultTimeZoneTest.java >> Test results: passed: 1 > > Vanitha B P has updated the pull request incrementally with one additional commit since the last revision: > > Vanitha B P Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27043#pullrequestreview-3181181899 From naoto at openjdk.org Wed Sep 3 15:24:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 15:24:46 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 00:57:39 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Objects.requireNonNull() > > src/java.base/share/classes/java/text/DateFormatSymbols.java line 148: > >> 146: * if the resources for the specified locale cannot be >> 147: * found or cannot be loaded. >> 148: * @throws NullPointerException if {@code locale} is null > > Adding an explicit Objects.requireNull(locale, "locale") would clearly identify when the NPE is thrown. > Though it might be earlier than without the check. Right. Added the explicit null check. (and a test case) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27060#discussion_r2319328408 From stefank at openjdk.org Wed Sep 3 15:28:52 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 15:28:52 GMT Subject: RFR: 8366298: FDLeakTest sometimes takes minutes to complete on Linux [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 08:03:27 GMT, Stefan Karlsson wrote: >> While investigating [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555), which lowers the timeout factor from 4 to 1, we found that FDLeakTest sometimes times out on Linux. >> >> The reason is that the test performs a `fcntl` call for each and every potential file descriptor number. This can be a large number of calls and sometimes results in minutes-long test executions. >> >> I propose that we fix this by limiting the max number of open file descriptors. This lowers the test execution time to about 1 second. >> >> The test has two processes. One that executes the libFDLeaker.c code below as an agent in the test JVM, then it forks into a exeFDLeakTester.c, which reads the property `int max_fd = (int)sysconf(_SC_OPEN_MAX);`. The setting of `RLIMIT_NOFILE` to `100` lowers `max_fd` to `100`. I've verified this on both Linux and on macOS. >> >> I've run the test manually on Linux and macOS and verified that it runs faster. I've also run this through tier1. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Remove jtreg timeouts > - Merge remote-tracking branch 'upstream/master' into 8366298_fdleaktest > - Add error logging > - 8366298: FDLeakTest sometimes takes minutes to complete on Linux :D Thanks for nudging the Skara bots. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26979#issuecomment-3249726291 From duke at openjdk.org Wed Sep 3 15:33:48 2025 From: duke at openjdk.org (Vanitha B P) Date: Wed, 3 Sep 2025 15:33:48 GMT Subject: Integrated: 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 09:22:16 GMT, Vanitha B P wrote: > Problem Statements: > 1. ZoneID is not updating when the user change the platform time zone setting, then click the "Update Time Zone" button. > 2. ZoneID was not displaying in the window as it is displaying in the lower releases. > > Test Results: > jdk-25.0.1/bin/java -jar jtreg/lib/jtreg.jar -verbose:summary -testjdk:jdk-25.0.1 -dir:open/test/jdk java/util/TimeZone/DefaultTimeZoneTest.java > > Passed: java/util/TimeZone/DefaultTimeZoneTest.java > Test results: passed: 1 This pull request has now been integrated. Changeset: a40afdd0 Author: Vanitha B P Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/a40afdd08f366afcefb1ac9d5fb184c8e803707e Stats: 30 lines in 1 file changed: 25 ins; 1 del; 4 mod 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected Reviewed-by: naoto, jlu ------------- PR: https://git.openjdk.org/jdk/pull/27043 From duke at openjdk.org Wed Sep 3 16:00:51 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 3 Sep 2025 16:00:51 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: <2Nr26Lga_Zpu8YeuivAfHs4CZRDElUU2neDNgNfFdUs=.830f7566-a724-4c1c-8aa3-870ccaafa0de@github.com> References: <2Nr26Lga_Zpu8YeuivAfHs4CZRDElUU2neDNgNfFdUs=.830f7566-a724-4c1c-8aa3-870ccaafa0de@github.com> Message-ID: <2gaPMgS08Q5cQZVg7a1OrJ_ZE0vicojJy0PWfWxcUXE=.a3cd6ed1-b95e-4133-9f1e-d263b8ed18c4@github.com> On Wed, 3 Sep 2025 15:55:48 GMT, Raffaello Giulietti wrote: >> @rgiulietti The code of my implementation provides it. > > @fabioromano1 If nobody leaves a comment in the next few days, I'll approve the PR around Monday next week. > > Thanks again for your hard work. @rgiulietti After the integration of this PR, I will open a new PR for the implementation of `BigDecimal.nthRoot()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3249849195 From rgiulietti at openjdk.org Wed Sep 3 16:00:50 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 3 Sep 2025 16:00:50 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: References: Message-ID: <2Nr26Lga_Zpu8YeuivAfHs4CZRDElUU2neDNgNfFdUs=.830f7566-a724-4c1c-8aa3-870ccaafa0de@github.com> On Mon, 1 Sep 2025 13:09:33 GMT, fabioromano1 wrote: >> Is there some documentation proving your claims in the CSR about the accuracy (1.1 ulp and 0.55 ulp, resp.)? > > @rgiulietti The code of my implementation provides it. @fabioromano1 If nobody leaves a comment in the next few days, I'll approve the PR around Monday next week. Thanks again for your hard work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3249841235 From liach at openjdk.org Wed Sep 3 16:01:45 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 16:01:45 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v12] In-Reply-To: References: Message-ID: <5rOnffce6J4teGGM8b_B_Iu1X0CaVFZaP1nHkHu0kzI=.c460b8f8-d4eb-40ec-931f-e010cad7d822@github.com> On Fri, 29 Aug 2025 06:45:25 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java > > change overflow check I recommend putting this PR on hold - 65535 encoded size for modified utf8 is significant enough for a cross-JDK utility. As @rose00 suggested, I think I will explore adding a check in ClassFile API, and sharing the check with here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3249851989 From jlu at openjdk.org Wed Sep 3 16:03:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Sep 2025 16:03:42 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 15:22:11 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/DateFormatSymbols.java line 148: >> >>> 146: * if the resources for the specified locale cannot be >>> 147: * found or cannot be loaded. >>> 148: * @throws NullPointerException if {@code locale} is null >> >> Adding an explicit Objects.requireNull(locale, "locale") would clearly identify when the NPE is thrown. >> Though it might be earlier than without the check. > > Right. Added the explicit null check. (and a test case) If we are adding an explicit check to the ctor, might we also take this opportunity to add the check to the related 1-arg factory method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27060#discussion_r2319435650 From rriggs at openjdk.org Wed Sep 3 16:19:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 16:19:45 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v4] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 07:54:46 GMT, Volkan Yazici wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revisited handling of IOExceptions to throw instead of completely ignoring or logging. > > test/jdk/java/lang/Process/ProcessCloseTest.java line 386: > >> 384: break; >> 385: } catch (InterruptedException ie) { >> 386: // retry above > > Are we sure about completely discarding the interrupt? No interrupts are expected, the test is modified to consider InterruptedException as a test failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2319474197 From rriggs at openjdk.org Wed Sep 3 16:28:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 16:28:45 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v4] In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 13:17:55 GMT, Roger Riggs wrote: >> What David said is right although it doesn't really make sense to extend Process, at least not outside the JDK. If the API were introduced today then it wouldn't have a public constructor, or maybe it would be a sealed hierarchy. It's possible of course that that there are Process implementations for testing or delegation but unlikely a "real implementation". > > Its easy enough to use an atomic update to achieve the idempotent behavior. > But two racing threads calling close raise the question of the state after close returns. > To assert that the process has been "closed" then both threads have to wait until its finished. > The normal developer would expect that close is complete after return; so somebody has to wait. A corpus search found a few overrides of Process. Some have overridden the `close` method to destroy the process, either by calling Process.destroy or directly using OS specific APIs. None of the `close` methods throw IOException, so not causing a source compatibility issue. None of them close the streams. The subclasses appear to help keep track of Processes or enhance communications over the standard streams. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2319496727 From scolebourne at joda.org Wed Sep 3 17:06:04 2025 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 3 Sep 2025 18:06:04 +0100 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: Hmm, yes. Not sure why that didn't get added in Java 8! The constants would be MAX/MIN as per classes like Instant. Stephen On Wed, 3 Sept 2025 at 12:50, Pavel Rappo wrote: > > Couldn't recall or quickly find if this was asked before. > > I come across this quite often: there doesn?t seem to be a readily > available maximum value for java.time.Duration -- a value that > represents the longest possible duration. > > I assume there are plenty of homegrown constants out in the wild > addressing this. Don?t get me wrong: it?s not hard to create one. The > issue, in my experience, is that it takes time and sometimes > experimentation. > > Unless one reads the Javadoc carefully, it?s not obvious that the > maximum duration can be constructed as follows: > > Duration.of(Long.MAX_VALUE, 999_999_999); > > Naturally, one might first try using IDE autocomplete. For example, > creating a Duration from Long.MAX_VALUE of a large unit -- millennia, > centuries, decades, etc. -- only to run into ArithmeticException. Only > when reaching seconds does it finally work: > > Duration.ofSeconds(Long.MAX_VALUE); > > or > > Duration.of(Long.MAX_VALUE, ChronoUnit.SECONDS); > > Of course, there?s no practical difference between > Duration.of(Long.MAX_VALUE, 999_999_999) and > Duration.ofSeconds(Long.MAX_VALUE). We?re talking about durations on > the order of 292 billion years, after all. The exact value isn?t the > problem. The problem is that the values are inconsistent, and arriving > to them is error-prone. Adding a constant to java.time.Duration would > simplify things. > > -Pavel From naoto at openjdk.org Wed Sep 3 17:06:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 17:06:32 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v3] In-Reply-To: References: Message-ID: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Further requireNonNull() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27060/files - new: https://git.openjdk.org/jdk/pull/27060/files/7b3d4e00..d7cb9566 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27060&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27060&range=01-02 Stats: 14 lines in 4 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27060/head:pull/27060 PR: https://git.openjdk.org/jdk/pull/27060 From naoto at openjdk.org Wed Sep 3 17:06:32 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 17:06:32 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 16:01:01 GMT, Justin Lu wrote: >> Right. Added the explicit null check. (and a test case) > > If we are adding an explicit check to the ctor, might we also take this opportunity to add the check to the related 1-arg factory method? Indeed. Also did the same for `DecimalFormatSymbols`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27060#discussion_r2319613332 From bpb at openjdk.org Wed Sep 3 17:10:41 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Sep 2025 17:10:41 GMT Subject: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v5] In-Reply-To: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> References: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> Message-ID: > Attempt to improve the verbiage of the `java.io.File` specification to make it clearer whether a given method operates only on an abstract pathname or on the actual file system entry it denotes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8366102: Further cleanup per review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27006/files - new: https://git.openjdk.org/jdk/pull/27006/files/6d3587e9..81b00c98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27006&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27006&range=03-04 Stats: 32 lines in 1 file changed: 0 ins; 0 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/27006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27006/head:pull/27006 PR: https://git.openjdk.org/jdk/pull/27006 From rgiulietti at openjdk.org Wed Sep 3 17:25:51 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 3 Sep 2025 17:25:51 GMT Subject: RFR: 8077587: BigInteger Roots [v78] In-Reply-To: <2gaPMgS08Q5cQZVg7a1OrJ_ZE0vicojJy0PWfWxcUXE=.a3cd6ed1-b95e-4133-9f1e-d263b8ed18c4@github.com> References: <2Nr26Lga_Zpu8YeuivAfHs4CZRDElUU2neDNgNfFdUs=.830f7566-a724-4c1c-8aa3-870ccaafa0de@github.com> <2gaPMgS08Q5cQZVg7a1OrJ_ZE0vicojJy0PWfWxcUXE=.a3cd6ed1-b95e-4133-9f1e-d263b8ed18c4@github.com> Message-ID: On Wed, 3 Sep 2025 15:58:17 GMT, fabioromano1 wrote: >> @fabioromano1 If nobody leaves a comment in the next few days, I'll approve the PR around Monday next week. >> >> Thanks again for your hard work. > > @rgiulietti After the integration of this PR, I will open a new PR for the implementation of `BigDecimal.nthRoot()`. @fabioromano1 There's a way to have dependent PRs, but it risks complicating merges with master. In your case, you could open a new PR for `BigDecimal` that depends on this one. However, I think that waiting some more days until this one is integrated is better. Anyway, [here's the explanation:](https://wiki.openjdk.org/display/SKARA#Skara-Dependentpullrequests). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3250123795 From naoto.sato at oracle.com Wed Sep 3 17:34:36 2025 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 3 Sep 2025 10:34:36 -0700 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: <33cc182d-33df-4e49-9309-ef1753c1396e@oracle.com> Filed an RFE: https://bugs.openjdk.org/browse/JDK-8366829 Naoto On 9/3/25 10:06 AM, Stephen Colebourne wrote: > Hmm, yes. Not sure why that didn't get added in Java 8! > The constants would be MAX/MIN as per classes like Instant. > Stephen > > > On Wed, 3 Sept 2025 at 12:50, Pavel Rappo wrote: >> >> Couldn't recall or quickly find if this was asked before. >> >> I come across this quite often: there doesn?t seem to be a readily >> available maximum value for java.time.Duration -- a value that >> represents the longest possible duration. >> >> I assume there are plenty of homegrown constants out in the wild >> addressing this. Don?t get me wrong: it?s not hard to create one. The >> issue, in my experience, is that it takes time and sometimes >> experimentation. >> >> Unless one reads the Javadoc carefully, it?s not obvious that the >> maximum duration can be constructed as follows: >> >> Duration.of(Long.MAX_VALUE, 999_999_999); >> >> Naturally, one might first try using IDE autocomplete. For example, >> creating a Duration from Long.MAX_VALUE of a large unit -- millennia, >> centuries, decades, etc. -- only to run into ArithmeticException. Only >> when reaching seconds does it finally work: >> >> Duration.ofSeconds(Long.MAX_VALUE); >> >> or >> >> Duration.of(Long.MAX_VALUE, ChronoUnit.SECONDS); >> >> Of course, there?s no practical difference between >> Duration.of(Long.MAX_VALUE, 999_999_999) and >> Duration.ofSeconds(Long.MAX_VALUE). We?re talking about durations on >> the order of 292 billion years, after all. The exact value isn?t the >> problem. The problem is that the values are inconsistent, and arriving >> to them is error-prone. Adding a constant to java.time.Duration would >> simplify things. >> >> -Pavel From pavel.rappo at gmail.com Wed Sep 3 17:43:15 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 3 Sep 2025 18:43:15 +0100 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne wrote: > > Hmm, yes. Not sure why that didn't get added in Java 8! > The constants would be MAX/MIN as per classes like Instant. > Stephen I thought that naming could be tricky :) The public constant Duration.ZERO and the public method isZero() are already there. However, it does not preclude us from naming a new constant MAX. From duke at openjdk.org Wed Sep 3 17:43:52 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 3 Sep 2025 17:43:52 GMT Subject: RFR: 8365467: Issues with jrtfs implementation for exploded run-time images [v2] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 14:22:11 GMT, Chen Liang wrote: >> Is that thumbs up and confirmation that you've checked it? > > @david-beaumont I think you need to override `getLocation` if you override `isResource` so image reader can actually fetch the data - unfortunately this is not clearly documented. Ooooh. That's interesting. So before, these nodes were none of the types resource, directory or link. And obviously that was working to an extent. And you're right that "isResource()" should imply "getResource()" works, but if that's the case, how can a JRT file system be built on top of this at all? I need to investigate more... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2319724975 From duke at openjdk.org Wed Sep 3 17:46:44 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 3 Sep 2025 17:46:44 GMT Subject: RFR: 8365467: Issues with jrtfs implementation for exploded run-time images [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 17:41:32 GMT, David Beaumont wrote: >> @david-beaumont I think you need to override `getLocation` if you override `isResource` so image reader can actually fetch the data - unfortunately this is not clearly documented. > > Ooooh. That's interesting. > So before, these nodes were none of the types resource, directory or link. > And obviously that was working to an extent. > And you're right that "isResource()" should imply "getResource()" works, but if that's the case, how can a JRT file system be built on top of this at all? > I need to investigate more... Ah no, there is not, and never was a "getResource()" method on the node class. Nodes are not inner classes and do not have access to the image. The getResource() method exists (both now and before my changes) on the ExplocedImage class. So I think what I've done here is correct, and no other changes are necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2319731082 From alanb at openjdk.org Wed Sep 3 17:49:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Sep 2025 17:49:49 GMT Subject: RFR: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications [v5] In-Reply-To: References: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> Message-ID: On Wed, 3 Sep 2025 17:10:41 GMT, Brian Burkhalter wrote: >> Attempt to improve the verbiage of the `java.io.File` specification to make it clearer whether a given method operates only on an abstract pathname or on the actual file system entry it denotes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8366102: Further cleanup per review comments Latest update looks good, I don't have any other comments. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27006#pullrequestreview-3181796654 From duke at openjdk.org Wed Sep 3 17:49:47 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 3 Sep 2025 17:49:47 GMT Subject: RFR: 8365467: Issues with jrtfs implementation for exploded run-time images [v2] In-Reply-To: <0QH_BCnliXbvJqh_KgxQliOe0u1HIOIPrgdoi_2sS5Y=.4b69938b-1d7b-439e-b1d8-fcb4852f0aa0@github.com> References: <0QH_BCnliXbvJqh_KgxQliOe0u1HIOIPrgdoi_2sS5Y=.4b69938b-1d7b-439e-b1d8-fcb4852f0aa0@github.com> Message-ID: On Sat, 30 Aug 2025 14:23:33 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 81: >> >>> 79: } >>> 80: >>> 81: private static final String RUNTIME_HOME; >> >> Hiding these prevents unwanted use by other classes (which would make them effectively untestable). > > You can still use Method handles and `@modules java.base/jdk.internal.jrtfs:+open` in JTReg to test these. Sure, but anyone who accesses these via method handles deserves all they get (imo). If these do need to be tested, they can be opened up again. Making them private is taking the temptation to just use them casually away from whoever edits these files next. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2319737044 From pavel.rappo at gmail.com Wed Sep 3 17:53:19 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 3 Sep 2025 18:53:19 +0100 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: If I understood you correctly, you think we should also add Duration.MIN. If so, what use case do you envision for it? Or we add if purely for symmetry with Instant? On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo wrote: > > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne wrote: > > > > Hmm, yes. Not sure why that didn't get added in Java 8! > > The constants would be MAX/MIN as per classes like Instant. > > Stephen > > I thought that naming could be tricky :) The public constant > Duration.ZERO and the public method isZero() are already there. > However, it does not preclude us from naming a new constant MAX. From liach at openjdk.org Wed Sep 3 17:59:45 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 17:59:45 GMT Subject: RFR: 8365467: Issues with jrtfs implementation for exploded run-time images [v2] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 17:44:33 GMT, David Beaumont wrote: >> Ooooh. That's interesting. >> So before, these nodes were none of the types resource, directory or link. >> And obviously that was working to an extent. >> And you're right that "isResource()" should imply "getResource()" works, but if that's the case, how can a JRT file system be built on top of this at all? >> I need to investigate more... > > Ah no, there is not, and never was a "getResource()" method on the node class. Nodes are not inner classes and do not have access to the image. > The getResource() method exists (both now and before my changes) on the ExplocedImage class. > So I think what I've done here is correct, and no other changes are necessary. I think this was the method I saw: https://github.com/openjdk/jdk/blob/1408def0c09c6da9cd1ba2b36a8c25de21f0f193/src/java.base/share/classes/jdk/internal/jimage/ImageReader.java#L572 It is package private so we cannot override it here. What is it for at all then... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2319767738 From jlu at openjdk.org Wed Sep 3 18:02:49 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Sep 2025 18:02:49 GMT Subject: Integrated: 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 18:00:25 GMT, Justin Lu wrote: > This PR addresses a JCK test failure related to `DecimalFormatSymbols` de-serialization. While the current public API of DFS disallows a null locale, it was possible to set in the past. Thus, the `loadNumberData(locale)` call currently throws NPE when locale is null in the stream. The call should be guarded with a null check, such that if locale is null, then `lenientMinusSigns` defaults to `minusSignText`. > > Defaulting the locale field when `null` to Locale.ROOT is also a reasonable solution, but I think that the current one is preferable as a user would not expect locale data related logic to occur if locale is `null`. This pull request has now been integrated. Changeset: e3b36e3b Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/e3b36e3babb860d9d24a610160f47d42cfaafaa3 Stats: 266 lines in 2 files changed: 265 ins; 0 del; 1 mod 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/27008 From asemenyuk at openjdk.org Wed Sep 3 18:05:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Sep 2025 18:05:55 GMT Subject: RFR: 8361207: Build native Windows ARM64 MSI packages In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:15:00 GMT, Armin Schrenk wrote: > Add support for native ARM64 Windows MSI pacakges to jpackage. > > For some reasoning and more info, check out the ticket on JBS: https://bugs.openjdk.org/browse/JDK-8361207. I just brought your case to the attention of OCA verification team. Hopefully, this will speed up the process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26093#issuecomment-3137974151 From duke at openjdk.org Wed Sep 3 18:05:55 2025 From: duke at openjdk.org (Armin Schrenk) Date: Wed, 3 Sep 2025 18:05:55 GMT Subject: RFR: 8361207: Build native Windows ARM64 MSI packages In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:15:00 GMT, Armin Schrenk wrote: > Add support for native ARM64 Windows MSI pacakges to jpackage. > > For some reasoning and more info, check out the ticket on JBS: https://bugs.openjdk.org/browse/JDK-8361207. This contribution is made on behalf of the Skymatic GmbH. @alexeysemenyukoracle can i speed up the OCA verification? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26093#issuecomment-3027476919 PR Comment: https://git.openjdk.org/jdk/pull/26093#issuecomment-3137629082 From duke at openjdk.org Wed Sep 3 18:05:54 2025 From: duke at openjdk.org (Armin Schrenk) Date: Wed, 3 Sep 2025 18:05:54 GMT Subject: RFR: 8361207: Build native Windows ARM64 MSI packages Message-ID: Add support for native ARM64 Windows MSI pacakges to jpackage. For some reasoning and more info, check out the ticket on JBS: https://bugs.openjdk.org/browse/JDK-8361207. ------------- Commit messages: - Add support for arm64 Platform for jpackage/WixPipeline Changes: https://git.openjdk.org/jdk/pull/26093/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26093&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361207 Stats: 36 lines in 2 files changed: 34 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26093.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26093/head:pull/26093 PR: https://git.openjdk.org/jdk/pull/26093 From asemenyuk at openjdk.org Wed Sep 3 18:05:56 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Sep 2025 18:05:56 GMT Subject: RFR: 8361207: Build native Windows ARM64 MSI packages In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 19:51:57 GMT, Armin Schrenk wrote: >> Add support for native ARM64 Windows MSI pacakges to jpackage. >> >> For some reasoning and more info, check out the ticket on JBS: https://bugs.openjdk.org/browse/JDK-8361207. > > @alexeysemenyukoracle can i speed up the OCA verification? @infeo have you received an OCA verification request? They sent it to you about three weeks ago. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26093#issuecomment-3229953243 From duke at openjdk.org Wed Sep 3 18:05:57 2025 From: duke at openjdk.org (Sebastian Stenzel) Date: Wed, 3 Sep 2025 18:05:57 GMT Subject: RFR: 8361207: Build native Windows ARM64 MSI packages In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:15:00 GMT, Armin Schrenk wrote: > Add support for native ARM64 Windows MSI pacakges to jpackage. > > For some reasoning and more info, check out the ticket on JBS: https://bugs.openjdk.org/browse/JDK-8361207. @robilad asked me to confirm @infeo's identity via email on August 1st. I replied within an hour. Can you please re-check your emails? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixFragmentBuilder.java line 166: > 164: } > 165: } > 166: isn't this enum definition redundant? Why not use `Architecture.current()` in WixPipeline's switch expressions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26093#issuecomment-3232432146 PR Review Comment: https://git.openjdk.org/jdk/pull/26093#discussion_r2249253253 From shaunspiller at gmail.com Wed Sep 3 18:21:53 2025 From: shaunspiller at gmail.com (Shaun Spiller) Date: Wed, 3 Sep 2025 19:21:53 +0100 Subject: Excessive copying of Collection.toArray() In-Reply-To: References: Message-ID: > Hello Shaun, note that the optimizing compiler in the JVM (C2) can likely eliminate 3 of the 4 copies, all except 1 (which is not a defensive copy). > 2 could be eliminated when escape analysis finds the result of HashSet.toArray does not escape beyond the toArray method, so subsequent clone is elided. > 4 could be eliminated when EA concludes the result of ArrayList.toArray does not escape beyond the toArray method, so subsequent clone is elided. > 3 could be eliminated when EA concludes the `ArrayList` does not escape beyond the sortedImmutableList method. This one is harder for compilers than the previous two. Thank you. I didn't know the JVM could potentially elide array clones, but I would say that either this optimization is insufficient, OR the optimizations that classes are currently using to avoid the clone are then redundant. It can't be both. > There have been previous attempts to reduce copying here and there, but they do suffer from the problems you have described. See https://github.com/openjdk/jdk/pull/12212 That's a valuable link. It touches on the same problem and potential solutions. It's a shame it was abandoned. This superficially simple problem touches performance, security, and bootstrapping and that scares people off. But I would still plead that there is some low-hanging fruit for improvement here. There are defensive clones and "is it an ArrayList (but not ArrayList subclass!!!)" optimizations copy-pasted in half a dozen scattered places. If that optimization is still valuable, it would benefit from a reusable utility method, where it can be centrally maintained, documented, and evangelized. If not, it should be deleted. Also, the knowledge of why the defensive clone is made at all, and why it must be of type Object[] and not a covariant subclass, these are currently arcane secrets held only by those who know the history of the associated bug reports. That's another part of why I argue for a central method that can be named and discussed. (I originally requested it in a webbug report, and was told it would be better discussed on the mailing list instead.) From rriggs at openjdk.org Wed Sep 3 18:42:43 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 18:42:43 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v12] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 06:45:25 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java > > change overflow check > /reviewers 2 reviewer > > I recommend putting this PR on hold - 65535 encoded size for modified utf8 is significant enough for a cross-JDK utility. As @rose00 suggested, I think I will explore adding a check in ClassFile API, and sharing the check with here. A common boolean function is useful and can be better optimized. The function should be in a common utility area, but the ClassFile API is a higher level API specific to class files. Most developers won't think to look there. The jdk.internal.util.ModifiedUtf isn't a bad place for both the boolean function and the utfLen function. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3250349748 From rriggs at openjdk.org Wed Sep 3 18:46:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 18:46:46 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v6] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 20:43:27 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > javadoc tweaks Please review the CSR: [JDK-8364362](https://bugs.openjdk.org/browse/JDK-8364362) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26649#issuecomment-3250360405 From jlu at openjdk.org Wed Sep 3 18:57:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Sep 2025 18:57:42 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v3] In-Reply-To: References: Message-ID: <7Bd0xA8GDgik-VMG1hitlHAm04HvNWq2muI1MZA6h0E=.8dc8f4c3-4f30-42a1-a38e-8a25618c28bc@github.com> On Wed, 3 Sep 2025 17:06:32 GMT, Naoto Sato wrote: >> Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further requireNonNull() Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27060#pullrequestreview-3182018697 From dmlloyd at openjdk.org Wed Sep 3 19:03:44 2025 From: dmlloyd at openjdk.org (David Lloyd) Date: Wed, 3 Sep 2025 19:03:44 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v6] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 20:43:27 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > javadoc tweaks src/java.base/share/classes/java/lang/Process.java line 664: > 662: ioe = quietClose(errorReader != null ? errorReader : getErrorStream(), ioe); > 663: > 664: destroy(); // no-op if process is not alive On some platforms, `destroy` and `destroyForcibly` behave differently. That means `close` would also behave differently depending on the platform. Maybe it should either always call `destroyForcibly` or else only call `destroy` if `supportsNormalTermination` (and otherwise hope that closing the streams is a good enough hint) to be consistent? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2319913955 From liach at openjdk.org Wed Sep 3 19:24:51 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 19:24:51 GMT Subject: RFR: 8361635: Missing List length validation in the Class-File API [v3] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 14:57:01 GMT, Chen Liang wrote: >> The `class` file format often only stores lists up to 65535 in size because size is encoded as a u2. Currently, we truncate the list size and write all contents, creating malformed `class` files. Almost all scenarios where such oversized lists are created can be considered an error; we should eagerly reject lists that would never be encodable in the `class` file format when users construct model objects. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-list-sizes > - Link to u1/u2 > - Merge branch 'fix/cf-u2-validation' into fix/cf-list-sizes > - Another missed spot > - Typo, thanks Adam > - Missed one link > - New u2 central info stage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-u2-validation > - Package-level information > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-list-sizes > - ... and 11 more: https://git.openjdk.org/jdk/compare/ae960772...0e74a9a5 Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26252#issuecomment-3250481175 From liach at openjdk.org Wed Sep 3 19:24:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Sep 2025 19:24:52 GMT Subject: Integrated: 8361635: Missing List length validation in the Class-File API In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:01:18 GMT, Chen Liang wrote: > The `class` file format often only stores lists up to 65535 in size because size is encoded as a u2. Currently, we truncate the list size and write all contents, creating malformed `class` files. Almost all scenarios where such oversized lists are created can be considered an error; we should eagerly reject lists that would never be encodable in the `class` file format when users construct model objects. This pull request has now been integrated. Changeset: 431f4672 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/431f46724658b703e995e518cb7a2149c50d6a9d Stats: 886 lines in 48 files changed: 775 ins; 20 del; 91 mod 8361635: Missing List length validation in the Class-File API Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/26252 From mdonovan at openjdk.org Wed Sep 3 19:35:27 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 3 Sep 2025 19:35:27 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms [v3] In-Reply-To: References: Message-ID: > In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read. Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - I removed signature algorithms output because the information is created during TLS handshake - Merge branch 'master' into secsettings - removed unused import, updated tools/launcher/Settings.java test - Merge branch 'master' into secsettings - 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24424/files - new: https://git.openjdk.org/jdk/pull/24424/files/b695a812..1e21e080 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24424&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24424&range=01-02 Stats: 65854 lines in 2051 files changed: 41068 ins; 17103 del; 7683 mod Patch: https://git.openjdk.org/jdk/pull/24424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24424/head:pull/24424 PR: https://git.openjdk.org/jdk/pull/24424 From kak at google.com Wed Sep 3 19:45:16 2025 From: kak at google.com (Kurt Alfred Kluever) Date: Wed, 3 Sep 2025 15:45:16 -0400 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: Hi all, Internally at Google, we've had a Durations.MAX constant exposed for the past 7 years. It now has about 700 usages across our depot, which I can try to categorize (at a future date). While I haven't performed that analysis yet, I think exposing this constant was a bit of a mistake. People seem to want to use MAX to mean "forever" (often in regards to an RPC deadline). This works fine as long as every single layer that touches the deadline is very careful about overflow. The only reasonable thing you can do with MAX is compareTo() and equals(). Attempting to do any simple math operation (e.g., now+deadline) is going to explode. Additionally, decomposing Duration.MAX explodes for any sub-second precision (e.g., toMillis()). As we dug into this, another proposal came up which was something like Durations.VERY_LONG. This duration would be longer than any reasonable finite duration but not long enough to cause an overflow when added to any reasonable time. E.g., a million years would probably satisfy both criteria. This would mean math operations and decompositions won't explode (well, microseconds and nanoseconds still would), and it could safely be used as a relative timeout. As I mentioned above, I'd be happy to try to categorize a sample of our 700 existing usages if folks think that would be useful for this proposal. Thanks, -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem team) On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo wrote: > If I understood you correctly, you think we should also add > Duration.MIN. If so, what use case do you envision for it? Or we add > if purely for symmetry with Instant? > > On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo wrote: > > > > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne > wrote: > > > > > > Hmm, yes. Not sure why that didn't get added in Java 8! > > > The constants would be MAX/MIN as per classes like Instant. > > > Stephen > > > > I thought that naming could be tricky :) The public constant > > Duration.ZERO and the public method isZero() are already there. > > However, it does not preclude us from naming a new constant MAX. > -- kak -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Sep 3 21:06:00 2025 From: duke at openjdk.org (duke) Date: Wed, 3 Sep 2025 21:06:00 GMT Subject: Withdrawn: 8356255: Add Stable Field Updaters to allow efficient lazy field evaluations In-Reply-To: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> References: <1Clu7NSEPGvbZOPaefBL_GgLH_WunJOw2zOOj-SyGlw=.b8446ffe-ff86-4175-ba8b-c618f9f703ba@github.com> Message-ID: On Mon, 5 May 2025 13:41:22 GMT, Per Minborg wrote: > This sketch shows how "Stable Updaters" can be used to create stable computations of `@Stable` fields. Only one updater is needed per class, similar to `AtomicIntegerFieldUpdater`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25040 From rriggs at openjdk.org Wed Sep 3 21:24:43 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 21:24:43 GMT Subject: RFR: 8366517: `DateFormatSymbols(Locale)` throws NPE if `Locale` argument is null [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 17:06:32 GMT, Naoto Sato wrote: >> Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further requireNonNull() Considerable scope creep here, the issue title and PR title should be updated. And the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27060#issuecomment-3250854288 From naoto at openjdk.org Wed Sep 3 21:39:42 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Sep 2025 21:39:42 GMT Subject: RFR: 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 21:22:16 GMT, Roger Riggs wrote: > Considerable scope creep here, the issue title and PR title should be updated. And the CSR. Modified ------------- PR Comment: https://git.openjdk.org/jdk/pull/27060#issuecomment-3250891660 From rriggs at openjdk.org Wed Sep 3 21:40:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 3 Sep 2025 21:40:45 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v6] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 19:00:26 GMT, David Lloyd wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc tweaks > > src/java.base/share/classes/java/lang/Process.java line 664: > >> 662: ioe = quietClose(errorReader != null ? errorReader : getErrorStream(), ioe); >> 663: >> 664: destroy(); // no-op if process is not alive > > On some platforms, `destroy` and `destroyForcibly` behave differently. That means `close` would also behave differently depending on the platform. Maybe it should either always call `destroyForcibly` or else only call `destroy` if `supportsNormalTermination` (and otherwise hope that closing the streams is a good enough hint) to be consistent? `DestroyForcibly` is an escalation that should only be used with a known poorly behaved process; and that's up to the programmer. It is the equivalent of `kill -9`. It should not be used in the normal case. Unfortunately, Windows does not have a polite, please terminate API so `destroy` has the same behavior as `destroyForcibly`. If the caller uses `process.waitFor()` within the try-catch, the process will have terminated, possibly based on the stream closings, and `destroy()` will not be called. If emphasis is needed, the javadoc can elaborate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2320282535 From jlu at openjdk.org Wed Sep 3 22:00:48 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Sep 2025 22:00:48 GMT Subject: Integrated: 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 In-Reply-To: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> References: <02TLmr4b78WC1ZSLPW0GsAgyoew4OwsFqbatVUuVvmY=.b49bb16a-6890-4ea7-bd8b-5ef2103981db@github.com> Message-ID: On Fri, 29 Aug 2025 23:59:54 GMT, Justin Lu wrote: > This PR addresses a JCK test failure of an unexpected SIOOBE during DecimalFormat parsing. During the char by char comparison in `matchAffix`, the minimum of the length of the parsed String and the PP index + affix length are iterated on. The parse position index needs to be checked to not be negative to ensure that we do not index the String below 0. Taking the minimum of those two previously mentioned values already guarantees that we do not index the String above the length. This pull request has now been integrated. Changeset: becc35f2 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/becc35f28792a48fac488841d0bc43226d7c96a7 Stats: 72 lines in 2 files changed: 60 ins; 9 del; 3 mod 8366400: JCK test api/java_text/DecimalFormat/Parse.html fails after JDK-8363972 Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/27014 From asemenyuk at openjdk.org Wed Sep 3 22:10:44 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Sep 2025 22:10:44 GMT Subject: RFR: 8361207: Build native Windows ARM64 MSI packages In-Reply-To: References: Message-ID: <1DGe2A-QZu0woGMhjw9Po-dtP6fjQbkpYHodWGXrA3c=.f712a864-879c-47de-822b-d6cf71568dc8@github.com> On Wed, 2 Jul 2025 11:15:00 GMT, Armin Schrenk wrote: > Add support for native ARM64 Windows MSI pacakges to jpackage. > > For some reasoning and more info, check out the ticket on JBS: https://bugs.openjdk.org/browse/JDK-8361207. Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java line 210: > 208: case Arch.X86 -> "x86"; > 209: case Arch.AARCH64 -> "arm64"; > 210: case Arch.OTHER -> throw new IOException("Unsupported architecture."); This would rather be an instance of `UnsupportedOperationException` src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java line 264: > 262: case Arch.X64 -> "x64"; > 263: case Arch.X86 -> "x86"; > 264: case Arch.AARCH64, Arch.OTHER -> throw new IOException("Unsupported architecture."); Is aarch64 packaging unsupported by WiX3? ------------- PR Review: https://git.openjdk.org/jdk/pull/26093#pullrequestreview-3182672122 PR Review Comment: https://git.openjdk.org/jdk/pull/26093#discussion_r2320331550 PR Review Comment: https://git.openjdk.org/jdk/pull/26093#discussion_r2320329066 From pavel.rappo at gmail.com Wed Sep 3 22:39:24 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 3 Sep 2025 23:39:24 +0100 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: This is useful; thanks. It would be good to see more of your data. My use case is also duration which practically means **forever**. I pass it to methods that accept timeouts, and expect these methods to correctly interpret it. One example of a practical interpretation is java.util.concurrent.TimeUnit.convert(Duration). This method never overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is roughly 292 years. Would I be okay, if the proposed duration didn't reflect **forever** but instead reflected **long enough**? I think so. But it still somehow feels wrong to make it less than maximum representable value. Personally, I'm not interested in calendar arithmetic, that is, in adding or subtracting durations. Others might be, and that's okay and needs to be factored in. For better or worse, java.time made a choice to be unforgiving in regard to overflow and is very upfront about it. It's not only proposed Duration.MAX. The same thing happens if you try this Instant.MAX.toEpochMilli() I guess my point is that doing calendar arithmetic on an unknown value is probably wrong. Doing it on a known huge/edge-case value is surely wrong. So back to your data. I would be interested to see what triggers overflows for your Durations.MAX. On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever wrote: > > Hi all, > > Internally at Google, we've had a Durations.MAX constant exposed for the past 7 years. It now has about 700 usages across our depot, which I can try to categorize (at a future date). > > While I haven't performed that analysis yet, I think exposing this constant was a bit of a mistake. People seem to want to use MAX to mean "forever" (often in regards to an RPC deadline). This works fine as long as every single layer that touches the deadline is very careful about overflow. The only reasonable thing you can do with MAX is compareTo() and equals(). Attempting to do any simple math operation (e.g., now+deadline) is going to explode. Additionally, decomposing Duration.MAX explodes for any sub-second precision (e.g., toMillis()). > > As we dug into this, another proposal came up which was something like Durations.VERY_LONG. This duration would be longer than any reasonable finite duration but not long enough to cause an overflow when added to any reasonable time. E.g., a million years would probably satisfy both criteria. This would mean math operations and decompositions won't explode (well, microseconds and nanoseconds still would), and it could safely be used as a relative timeout. > > As I mentioned above, I'd be happy to try to categorize a sample of our 700 existing usages if folks think that would be useful for this proposal. > > Thanks, > > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem team) > > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo wrote: >> >> If I understood you correctly, you think we should also add >> Duration.MIN. If so, what use case do you envision for it? Or we add >> if purely for symmetry with Instant? >> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo wrote: >> > >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne wrote: >> > > >> > > Hmm, yes. Not sure why that didn't get added in Java 8! >> > > The constants would be MAX/MIN as per classes like Instant. >> > > Stephen >> > >> > I thought that naming could be tricky :) The public constant >> > Duration.ZERO and the public method isZero() are already there. >> > However, it does not preclude us from naming a new constant MAX. > > > > -- > kak From ecki at zusammenkunft.net Wed Sep 3 23:59:31 2025 From: ecki at zusammenkunft.net (ecki) Date: Thu, 4 Sep 2025 01:59:31 +0200 Subject: Duration.MAX_VALUE In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From kak at google.com Thu Sep 4 00:21:44 2025 From: kak at google.com (Kurt Alfred Kluever) Date: Wed, 3 Sep 2025 20:21:44 -0400 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: Duration.MIN is a whole 'nother bag of worms, because Durations are signed (they can be positive or negative...or zero). Internally we also have Durations.MIN, but it's not public ... and along with it, I left myself a helpful note about naming: /** The minimum supported {@code Duration}, approximately -292 billion years. */ // Note: before making this constant public, consider that "MIN" might not be a great name (not // everyone knows that Durations can be negative!). static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); This reminds me of Double.MIN_VALUE (which is the smallest _positive_ double value) --- we've seen Double.MIN_VALUE misused so much that we introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large percent of Double.MIN_VALUE users actually want the smallest possible negative value, aka -Double.MAX_VALUE. If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE). On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: > If you ask me, I don?t find it very useful, It won?t work for > arithmetrics, even the APIs would have a hard time using it (how do you > express the deadline) and APIs with a timeout parameter do have a good > reason for it, better pick ?possible? values for better self healing and > unstuck of systems. In fact I would err on the smaller side in combination > with expecting spurious wakeups. > > BTW, when you introduce MIN as well, maybe also think about min precision, > min delta or such. Will it always be 1 nano? > > Gru?, > Bernd > -- > https://bernd.eckenfels.net > ------------------------------ > *Von:* core-libs-dev im Auftrag von > Pavel Rappo > *Gesendet:* Donnerstag, September 4, 2025 12:41 AM > *An:* Kurt Alfred Kluever > *Cc:* Stephen Colebourne ; core-libs-dev < > core-libs-dev at openjdk.org> > *Betreff:* Re: Duration.MAX_VALUE > > This is useful; thanks. It would be good to see more of your data. > > My use case is also duration which practically means **forever**. I > pass it to methods that accept timeouts, and expect these methods to > correctly interpret it. > > One example of a practical interpretation is > java.util.concurrent.TimeUnit.convert(Duration). This method never > overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is > roughly 292 years. > > Would I be okay, if the proposed duration didn't reflect **forever** > but instead reflected **long enough**? I think so. But it still > somehow feels wrong to make it less than maximum representable value. > > Personally, I'm not interested in calendar arithmetic, that is, in > adding or subtracting durations. Others might be, and that's okay and > needs to be factored in. For better or worse, java.time made a choice > to be unforgiving in regard to overflow and is very upfront about it. > It's not only proposed Duration.MAX. The same thing happens if you try > this > > Instant.MAX.toEpochMilli() > > I guess my point is that doing calendar arithmetic on an unknown value > is probably wrong. Doing it on a known huge/edge-case value is surely > wrong. So back to your data. I would be interested to see what > triggers overflows for your Durations.MAX. > > On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever > wrote: > > > > Hi all, > > > > Internally at Google, we've had a Durations.MAX constant exposed for the > past 7 years. It now has about 700 usages across our depot, which I can try > to categorize (at a future date). > > > > While I haven't performed that analysis yet, I think exposing this > constant was a bit of a mistake. People seem to want to use MAX to mean > "forever" (often in regards to an RPC deadline). This works fine as long as > every single layer that touches the deadline is very careful about > overflow. The only reasonable thing you can do with MAX is compareTo() and > equals(). Attempting to do any simple math operation (e.g., now+deadline) > is going to explode. Additionally, decomposing Duration.MAX explodes for > any sub-second precision (e.g., toMillis()). > > > > As we dug into this, another proposal came up which was something like > Durations.VERY_LONG. This duration would be longer than any reasonable > finite duration but not long enough to cause an overflow when added to any > reasonable time. E.g., a million years would probably satisfy both > criteria. This would mean math operations and decompositions won't explode > (well, microseconds and nanoseconds still would), and it could safely be > used as a relative timeout. > > > > As I mentioned above, I'd be happy to try to categorize a sample of our > 700 existing usages if folks think that would be useful for this proposal. > > > > Thanks, > > > > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem > team) > > > > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo > wrote: > >> > >> If I understood you correctly, you think we should also add > >> Duration.MIN. If so, what use case do you envision for it? Or we add > >> if purely for symmetry with Instant? > >> > >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo > wrote: > >> > > >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne < > scolebourne at joda.org> wrote: > >> > > > >> > > Hmm, yes. Not sure why that didn't get added in Java 8! > >> > > The constants would be MAX/MIN as per classes like Instant. > >> > > Stephen > >> > > >> > I thought that naming could be tricky :) The public constant > >> > Duration.ZERO and the public method isZero() are already there. > >> > However, it does not preclude us from naming a new constant MAX. > > > > > > > > -- > > kak > > -- kak -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at oracle.com Thu Sep 4 01:32:18 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 3 Sep 2025 21:32:18 -0400 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: Hi, I'd be interested in the range of use cases for Duration.MAX or MIN. But for deadlines, I think the code should compute the deadline from a Duration of its choice based on the use. Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores information about the particular use that is relevant. Its just sloppy code that doesn't bother to express how long is long enough to meet operational parameters. YMMV, Roger On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: > Duration.MIN is a whole 'nother bag of worms, because Durations are > signed (they can be positive or negative...or zero). Internally we > also have Durations.MIN, but it's not public?... and along with it, I > left myself a helpful note?about naming: > > ? /** The minimum supported {@code Duration}, approximately -292 > billion years. */ > ? // Note: before making this constant public, consider that "MIN" > might not be a great name (not > ? // ? ? ? everyone knows that Durations can be negative!). > ? static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); > > This reminds me of Double.MIN_VALUE (which is the smallest _positive_ > double value) --- we've seen Double.MIN_VALUE misused so much that we > introduced Doubles.MIN_POSITIVE_VALUE as a more?descriptive alias. A > large percent of Double.MIN_VALUE users actually want the smallest > possible negative value, aka -Double.MAX_VALUE. > > If we introduce Duration.MIN, I hope it would not be > Duration.ofNanos(1), but rather?Duration.ofSeconds(Long.MIN_VALUE). > > On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: > > If you ask me, I don?t find it very useful, It won?t work for > arithmetrics, even the APIs would have a hard time using it (how > do you express the deadline) and APIs with a timeout parameter do > have a good reason for it, better pick ?possible? values for > better self healing and unstuck of systems. In fact I would err on > the smaller side in combination with expecting spurious wakeups. > > BTW, when you introduce MIN as well, maybe also think about min > precision, min delta or such. Will it always be 1 nano? > > Gru?, > Bernd > -- > https://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:*?core-libs-dev im Auftrag > von Pavel Rappo > *Gesendet:*?Donnerstag, September 4, 2025 12:41 AM > *An:*?Kurt Alfred Kluever > *Cc:*?Stephen Colebourne ; core-libs-dev > > *Betreff:*?Re: Duration.MAX_VALUE > This is useful; thanks. It would be good to see more of your data. > > My use case is also duration which practically means **forever**. I > pass it to methods that accept timeouts, and expect these methods to > correctly interpret it. > > One example of a practical interpretation is > java.util.concurrent.TimeUnit.convert(Duration). This method never > overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is > roughly 292 years. > > Would I be okay, if the proposed duration didn't reflect **forever** > but instead reflected **long enough**? I think so. But it still > somehow feels wrong to make it less than maximum representable value. > > Personally, I'm not interested in calendar arithmetic, that is, in > adding or subtracting durations. Others might be, and that's okay and > needs to be factored in. For better or worse, java.time made a choice > to be unforgiving in regard to overflow and is very upfront about it. > It's not only proposed Duration.MAX. The same thing happens if you > try > this > > Instant.MAX.toEpochMilli() > > I guess my point is that doing calendar arithmetic on an unknown > value > is probably wrong. Doing it on a known huge/edge-case value is surely > wrong. So back to your data. I would be interested to see what > triggers overflows for your Durations.MAX. > > On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever > wrote: > > > > Hi all, > > > > Internally at Google, we've had a Durations.MAX constant exposed > for the past 7 years. It now has about 700 usages across our > depot, which I can try to categorize (at a future date). > > > > While I haven't performed that analysis yet, I think exposing > this constant was a bit of a mistake. People seem to want to use > MAX to mean "forever" (often in regards to an RPC deadline). This > works fine as long as every single layer that touches the deadline > is very careful about overflow. The only reasonable thing you can > do with MAX is compareTo() and equals(). Attempting to do any > simple math operation (e.g., now+deadline) is going to explode. > Additionally, decomposing Duration.MAX explodes for any sub-second > precision (e.g., toMillis()). > > > > As we dug into this, another proposal came up which was > something like Durations.VERY_LONG. This duration would be longer > than any reasonable finite duration but not long enough to cause > an overflow when added to any reasonable time. E.g., a million > years would probably satisfy both criteria. This would mean math > operations and decompositions won't explode (well, microseconds > and nanoseconds still would), and it could safely be used as a > relative timeout. > > > > As I mentioned above, I'd be happy to try to categorize a sample > of our 700 existing usages if folks think that would be useful for > this proposal. > > > > Thanks, > > > > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin > Ecosystem team) > > > > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo > wrote: > >> > >> If I understood you correctly, you think we should also add > >> Duration.MIN. If so, what use case do you envision for it? Or > we add > >> if purely for symmetry with Instant? > >> > >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo > wrote: > >> > > >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne > wrote: > >> > > > >> > > Hmm, yes. Not sure why that didn't get added in Java 8! > >> > > The constants would be MAX/MIN as per classes like Instant. > >> > > Stephen > >> > > >> > I thought that naming could be tricky :) The public constant > >> > Duration.ZERO and the public method isZero() are already there. > >> > However, it does not preclude us from naming a new constant MAX. > > > > > > > > -- > > kak > > > > -- > kak -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Thu Sep 4 03:17:29 2025 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 3 Sep 2025 20:17:29 -0700 Subject: Excessive copying of Collection.toArray() In-Reply-To: References: Message-ID: <4543dc86-0de7-47dd-8e3d-8872005d4d89@oracle.com> Hi Shaun, You got pretty far with your analysis; congratulations! It would indeed be nice to avoid excess copying. The crux of the matter is, as you concluded, how one can know whether to trust the caller. As you surmised the "only trust ArrayList" policy is merely a stopgap. You already proposed and knocked down the "obvious solution" which is to trust JDK classes (which are loaded by the boot classloader). Similar simple solutions, such as an allowlist with `instanceof` checks, can be defeated by subclassing. OK, maybe use getClass() instead. Now we have an allowlist that loads all the classes that it mentions, possibly unnecessarily. Hmmm. Using a private interface of some sort is an interesting technique to explore, but one needs to be careful about subclassing. (Actually it would probably be a public interface in jdk.internal.util or nearby, but not exported.) And of course we'd want to avoid having random logic sprinkled all around the JDK, so the "safeToArray" logic and implementation would have to be factored so that it's nicely centralized. But this would still leave non-JDK classes out in the cold. An arrangement that could work would be to have some construct that allows the creation of and writing to an array, but which precludes the possibility of retaining a reference to the array (or perhaps merely preventing writes to it after a certain point). One could imagine a library construct that implements this. Of course it would require classes to opt into this arrangement. Ordinary implementors of toArray() would still suffer an extra copy. But maybe this is overkill, and the best is the enemy of the good. Perhaps we could add a short allowlist that contains just the most frequently-used JDK classes. This wouldn't be exhaustive, but it could help the situation by covering more of the common cases. I was going to file an enhancement request for this, but there already is one: https://bugs.openjdk.org/browse/JDK-8257475 I filed it several years ago. :blush: s'marks On 9/2/25 11:19 AM, Shaun Spiller wrote: > Hello! > > Please consider the following real utility method I have: > > /** > * Returns an immutable list via {@link List#of} that is the > * sorted content of the collection. > */ > public static @NonNull List sortedImmutableList( > @NonNull Collection col, > @Nullable Comparator comparator) { > ArrayList list = new ArrayList<>(col); > list.sort(comparator); > return List.copyOf(list); > } > > Quiz question: Assume this method is invoked with a large HashSet as > its collection argument. How many ARRAY copies of the collection are > created by this method? Clearly there must be at least one for the > result, held internally in the immutable list. Any others? > > > (Scroll for the answer.) > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > . > > I was surprised to realize the answer is four: > > 1. ArrayList calls toArray() on the HashSet. > 2. ArrayList defensively copies the array to assign to its internal > elementData field, because it doesn't trust HashSet. > 3. List.copyOf calls toArray() on the ArrayList. > 4. List.of defensively copies the array to assign to its internal > elements field, because it doesn't trust ArrayList. > > It is quite possible to rewrite my particular utility method with a > raw array instead of ArrayList, to eliminate 2 array copies, but this > requires an icky unchecked cast, and by rights is the kind of thing > that shouldn't be necessary anyway. > > ----- > > In general, this kind of excessive defensive copying is going on ALL THE TIME. > > The underlying nuisance is that a subclass of Collection could > potentially override toArray() to keep a reference to the returned > array and make mischief with it. (Also, for ArrayList, it would be a > problem if the returned array were a subclass of Object[].) > > I did a search thru the JDK and found a slew of cases where code calls > Collection.toArray() and then has to worry about defensively copying > it -- or trying to avoid defensively copying it: > > - java.util.List.copyOf(Collection) -- avoids copying an existing > List.of/copyOf list, but for any other collection it calls toArray() > and then defensively copies it again > > - java.util.ArrayList(Collection) -- constructor has a special check > `if (collection.getClass() == ArrayList.class)`, in which case it > skips the defensive copy and trusts the result of toArray(), but it > does not trust any other collection > > - java.util.Vector(Collection) -- constructor has the same > optimization trick as ArrayList, where it trusts ArrayList, but > creates a defensive copy for any other collection. Vector doesn't even > trust itself! > > - java.util.PriorityQueue.initElementsFromCollection(Collection) -- > has optimization for ArrayList, but no other collection > > - java.util.concurrent.PriorityBlockingQueue(Collection) -- has > optimization for ArrayList, but no other collection > > - java.util.concurrent.CopyOnWriteArrayList(Collection) -- has > optimizations for ArrayList and CopyOnWriteArrayList, but no other > collection. > > - java.util.concurrent.CopyOnWriteArrayList.addAllAbsent(Collection) > -- has optimization for ArrayList but no other collection. > > - java.util.stream.Collectors.toUnmodifiableList() -- this avoids an > excess copy, but does so in a very complicated way > > - sun.awt.util.IdentityArrayList(Collection) -- this appears to be an > old copy-paste of ArrayList except with identity indexOf; like > pre-2020 ArrayList, it blindly trusts that `col.toArray()` returns a > new array, although based on this class's extremely limited use there > is no manifestable bug. > > - java.lang.invoke.MethodHandles.dropArguments/dropArgumentsToMatch -- > these call `list.toArray()` and then clone the array unconditionally > > - java.time.zone.ZoneRules.of(...) -- calls `lastRules.toArray()` and > then clones the array unconditionally > > ----- > > I would suggest that there should be an internal utility method for > use in all these cases, something like: > > public static Object[] safeToArray(Collection c) { > Object[] a = c.toArray(); > if (!isTrusted(c)) { > a = Arrays.copyOf(a, a.length, Object[].class); > } > return a; > } > > The delicate issue then is: what is the correct design of "isTrusted"? > The check must be fast, and not spoofable by classes outside the JDK. > > My first thought was to detect that the class is loaded by the > bootstrap class loader: > > static boolean isTrusted(Collection c) { > return c.getClass().getClassLoader() == null; > } > > However, I now realize this is unwise because it would shift the > burden of trust into **every** Collection class in the JDK, instead of > into the classes that actually care about the result. For example, > Collections.UnmodifiableCollection.toArray() simply returns the result > of its internal `col.toArray()`, which immediately carves a hole the > size of a bus thru the check. > > Perhaps better would be for classes to explicitly opt-in and say "Yes, > I promise that my toArray() method is safe". Would a package-private > marker interface work for this? > > I am not sure. > > Anyway, the point is that classes within the JDK should not need to > create so many defensive copies of each other. > > Note that this is becoming more of an issue now that List.of is > becoming a popular "go-to" list for many situations where ArrayList > would traditionally have been used. The "only trust ArrayList" pattern > was never ideal and is starting to age. > > This is my first post here so I apologize for oversights in formatting > or etiquette. > Thanks for reading. From stuart.marks at oracle.com Thu Sep 4 03:55:13 2025 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 3 Sep 2025 20:55:13 -0700 Subject: Excessive copying of Collection.toArray() In-Reply-To: References: Message-ID: >> There have been previous attempts to reduce copying here and there, but they do suffer from the problems you have described. See https://github.com/openjdk/jdk/pull/12212 > > That's a valuable link. It touches on the same problem and potential > solutions. It's a shame it was abandoned. This superficially simple > problem touches performance, security, and bootstrapping and that > scares people off. I think that PR is a good example of why we don't like to start off with code. As you noted there are a bunch of subtleties to the problem. Starting off with a PR with code mixes the fundamental issues with coding issues and the whole thing goes off into the weeds. If the code was written under the assumption that it was trying to solve problem A, but the real problem is problem B, then it turns into an uphill struggle to convert the existing code from solving problem A to solving problem B. Or worse, the code change bounces around trying to solve several problems but solves none of them well. (There have been several other examples of this phenomenon.) > But I would still plead that there is some low-hanging fruit for > improvement here. There are defensive clones and "is it an ArrayList > (but not ArrayList subclass!!!)" optimizations copy-pasted in half a > dozen scattered places. If that optimization is still valuable, it > would benefit from a reusable utility method, where it can be > centrally maintained, documented, and evangelized. If not, it should > be deleted. Agreed, a simple-though-incomplete approach might provide some useful improvements in the short term. > Also, the knowledge of why the defensive clone is made at all, and why > it must be of type Object[] and not a covariant subclass, these are > currently arcane secrets held only by those who know the history of > the associated bug reports. That's another part of why I argue for a > central method that can be named and discussed. (I originally > requested it in a webbug report, and was told it would be better > discussed on the mailing list instead.) Two issues here. The need for an extra defensive copy was established and fixed via the security vulnerability process and as such, all discussion of it was embargoed. Sorry. However, the sources are all out there and if you look at the code prior to commit [1] you can see the vulnerable code. Also, the eagle-eyed Heinz Kabutz noticed this and wrote about it in his Java Specialists' newsletter [2]. (Leave it to Heinz to relate the ArrayList.class check to the particular local origin of Cretan vegetables.) But I think you've discerned the issue yourself already. The second issue is that, by specification, the array returned by the no-arg toArray() method must have a component type of Object. The specification previously wasn't clear about this, and this led to a variety of bugs. See [3] and bugs linked from there. Now, *why* is it specified this way? Well, the static return type of toArray() is Object[], which leads callers to believe they can store any object into it. If toArray() were to return an array with some other component type, they'd get ArrayStoreException. So, the spec requires that you get what it says on the tin. s'marks [1]: https://github.com/openjdk/jdk/commit/343ecd806bb05065d31124573b3e58a864cfc617 [2]: https://www.javaspecialists.eu/archive/Issue290-CopyOnWriteArrayList-and-Collection.toArray.html [3]: https://bugs.openjdk.org/browse/JDK-8160406 From vyazici at openjdk.org Thu Sep 4 06:50:18 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 06:50:18 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods Message-ID: [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 ------------- Commit messages: - Further simplify sneaky-throws in `String` - Fix `StringSupport` - Revert "8366693: Backout recent JavaLangAccess changes breaking the build" Changes: https://git.openjdk.org/jdk/pull/27084/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366765 Stats: 465 lines in 9 files changed: 242 ins; 122 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 06:50:18 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 06:50:18 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Commits are consisted of the following: 1. f3e7c130391 Revert the revert 2. 3ea1d5ea009 Fix `StringSupport` 3. b48def1a22d Further simplify sneaky-throws in `String` (via @dfuch) Started `tier1,2` against b48def1a22d on 2025-09-03T07:50:32Z, and it successfully completed on 2025-09-03T14:10:35Z. Results are attached to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252150408 From stefank at openjdk.org Thu Sep 4 07:11:36 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 07:11:36 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info Message-ID: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. ------------- Commit messages: - 8366854: Extend jtreg failure handler with THP info Changes: https://git.openjdk.org/jdk/pull/27086/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27086&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366854 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27086/head:pull/27086 PR: https://git.openjdk.org/jdk/pull/27086 From stefank at openjdk.org Thu Sep 4 07:11:36 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 07:11:36 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info In-Reply-To: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:03:01 GMT, Stefan Karlsson wrote: > I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. > > This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. The proposed changes give the following output the environment.html file: * [proc_meminfo](file:///Users/stefank/environment.html#linux.memory.proc_meminfo) ---------------------------------------- [2025-09-02 17:03:04] [/usr/bin/bash, -c, cat /proc/meminfo] timeout=20000 in /home/stefank/git/jdk/build/fastdebug/test-support/jtreg_open_test_hotspot_jtreg_gc_g1_TestPLABOutput_java/gc/g1/TestPLABOutput ---------------------------------------- MemTotal: 64203564 kB MemFree: 28834780 kB MemAvailable: 61539920 kB Buffers: 1414464 kB Cached: 29551908 kB SwapCached: 0 kB Active: 4403292 kB Inactive: 27055328 kB Active(anon): 534448 kB Inactive(anon): 0 kB Active(file): 3868844 kB Inactive(file): 27055328 kB Unevictable: 21916 kB Mlocked: 21916 kB SwapTotal: 2097148 kB SwapFree: 2097148 kB Zswap: 0 kB Zswapped: 0 kB Dirty: 228 kB Writeback: 0 kB AnonPages: 514180 kB Mapped: 394392 kB Shmem: 30936 kB KReclaimable: 2503268 kB Slab: 3214280 kB SReclaimable: 2503268 kB SUnreclaim: 711012 kB KernelStack: 11312 kB PageTables: 11148 kB SecPageTables: 7988 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 34198928 kB Committed_AS: 2906292 kB VmallocTotal: 34359738367 kB VmallocUsed: 83464 kB VmallocChunk: 0 kB Percpu: 150336 kB HardwareCorrupted: 0 kB AnonHugePages: 88064 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB Unaccepted: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 485000 kB DirectMap2M: 11773952 kB DirectMap1G: 54525952 kB ---------------------------------------- [2025-09-02 17:03:04] exit code: 0 time: 5 ms ---------------------------------------- * [proc_vmstat](file:///Users/stefank/environment.html#linux.memory.proc_vmstat) ---------------------------------------- [2025-09-02 17:03:04] [/usr/bin/bash, -c, cat /proc/vmstat] timeout=20000 in /home/stefank/git/jdk/build/fastdebug/test-support/jtreg_open_test_hotspot_jtreg_gc_g1_TestPLABOutput_java/gc/g1/TestPLABOutput ---------------------------------------- nr_free_pages 7208695 nr_zone_inactive_anon 0 nr_zone_active_anon 133612 nr_zone_inactive_file 6763832 nr_zone_active_file 967211 nr_zone_unevictable 5479 nr_zone_write_pending 57 nr_mlock 5479 nr_bounce 0 nr_zspages 0 nr_free_cma 0 nr_unaccepted 0 numa_hit 466716436 numa_miss 0 numa_foreign 0 numa_interleave 2079 numa_local 466714954 numa_other 0 nr_inactive_anon 0 nr_active_anon 133612 nr_inactive_file 6763832 nr_active_file 967211 nr_unevictable 5479 nr_slab_reclaimable 625817 nr_slab_unreclaimable 177753 nr_isolated_anon 0 nr_isolated_file 0 workingset_nodes 0 workingset_refault_anon 0 workingset_refault_file 0 workingset_activate_anon 0 workingset_activate_file 0 workingset_restore_anon 0 workingset_restore_file 0 workingset_nodereclaim 0 nr_anon_pages 128545 nr_mapped 98598 nr_file_pages 7741593 nr_dirty 57 nr_writeback 0 nr_writeback_temp 0 nr_shmem 7734 nr_shmem_hugepages 0 nr_shmem_pmdmapped 0 nr_file_hugepages 0 nr_file_pmdmapped 0 nr_anon_transparent_hugepages 43 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_dirtied 25991300 nr_written 22813677 nr_throttled_written 0 nr_kernel_misc_reclaimable 0 nr_foll_pin_acquired 55140 nr_foll_pin_released 55140 nr_kernel_stack 11312 nr_page_table_pages 2787 nr_sec_page_table_pages 1997 nr_iommu_pages 1997 nr_swapcached 0 pgpromote_success 0 pgpromote_candidate 0 pgdemote_kswapd 0 pgdemote_direct 0 pgdemote_khugepaged 0 nr_dirty_threshold 2964299 nr_dirty_background_threshold 1480339 nr_memmap_pages 32768 nr_memmap_boot_pages 261120 pgpgin 10093202 pgpgout 98915825 pswpin 0 pswpout 0 pgalloc_dma 1024 pgalloc_dma32 1034 pgalloc_normal 478327697 pgalloc_movable 0 pgalloc_device 0 allocstall_dma 0 allocstall_dma32 0 allocstall_normal 0 allocstall_movable 0 allocstall_device 0 pgskip_dma 0 pgskip_dma32 0 pgskip_normal 0 pgskip_movable 0 pgskip_device 0 pgfree 485576492 pgactivate 0 pgdeactivate 50 pglazyfree 52187 pgfault 490762863 pgmajfault 24328 pglazyfreed 0 pgrefill 0 pgreuse 27798266 pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgscan_kswapd 0 pgscan_direct 0 pgscan_khugepaged 0 pgscan_direct_throttle 0 pgscan_anon 0 pgscan_file 0 pgsteal_anon 0 pgsteal_file 0 zone_reclaim_failed 0 pginodesteal 0 slabs_scanned 0 kswapd_inodesteal 0 kswapd_low_wmark_hit_quickly 0 kswapd_high_wmark_hit_quickly 0 pageoutrun 0 pgrotated 23017 drop_pagecache 0 drop_slab 0 oom_kill 0 numa_pte_updates 0 numa_huge_pte_updates 0 numa_hint_faults 0 numa_hint_faults_local 0 numa_pages_migrated 0 pgmigrate_success 0 pgmigrate_fail 0 thp_migration_success 0 thp_migration_fail 0 thp_migration_split 0 compact_migrate_scanned 0 compact_free_scanned 0 compact_isolated 0 compact_stall 0 compact_fail 0 compact_success 0 compact_daemon_wake 0 compact_daemon_migrate_scanned 0 compact_daemon_free_scanned 0 htlb_buddy_alloc_success 0 htlb_buddy_alloc_fail 0 unevictable_pgs_culled 34000 unevictable_pgs_scanned 4050 unevictable_pgs_rescued 5476 unevictable_pgs_mlocked 6905 unevictable_pgs_munlocked 1426 unevictable_pgs_cleared 0 unevictable_pgs_stranded 0 thp_fault_alloc 12586 thp_fault_fallback 0 thp_fault_fallback_charge 0 thp_collapse_alloc 241 thp_collapse_alloc_failed 0 thp_file_alloc 0 thp_file_fallback 0 thp_file_fallback_charge 0 [thp](file:///Users/stefank/environment.html#linux.memory.thp)_file_mapped 0 thp_split_page 0 thp_split_page_failed 0 thp_deferred_split_page 62 thp_split_pmd 269 thp_scan_exceed_none_pte 0 thp_scan_exceed_swap_pte 0 thp_scan_exceed_share_pte 9 thp_split_pud 0 thp_zero_page_alloc 1 thp_zero_page_alloc_failed 0 thp_swpout 0 thp_swpout_fallback 0 balloon_inflate 0 balloon_deflate 0 balloon_migrate 0 swap_ra 0 swap_ra_hit 0 ksm_swpin_copy 0 cow_ksm 0 zswpin 0 zswpout 0 zswpwb 0 direct_map_level2_splits 224 direct_map_level3_splits 8 nr_unstable 0 ---------------------------------------- [2025-09-02 17:03:04] exit code: 0 time: 4 ms ---------------------------------------- * thp ---------------------------------------- [2025-09-02 17:03:04] [/usr/bin/bash, -c, cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag}] timeout=20000 in /home/stefank/git/jdk/build/fastdebug/test-support/jtreg_open_test_hotspot_jtreg_gc_g1_TestPLABOutput_java/gc/g1/TestPLABOutput ---------------------------------------- always [madvise] never always defer defer+madvise madvise [never] ---------------------------------------- [2025-09-02 17:03:04] exit code: 0 time: 5 ms ------------- PR Comment: https://git.openjdk.org/jdk/pull/27086#issuecomment-3252227582 From alanb at openjdk.org Thu Sep 4 07:22:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Sep 2025 07:22:42 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Can you confirm that the only change from before is the update to src/java.base/share/classes/jdk/internal/foreign/StringSupport.java to deal with the "new" usage there? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252266512 From sjohanss at openjdk.org Thu Sep 4 07:33:41 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 4 Sep 2025 07:33:41 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info In-Reply-To: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:03:01 GMT, Stefan Karlsson wrote: > I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. > > This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. Thanks for fixing this @stefank This was really helpful when we debugged a THP issue recently, so good to get it into the mainline. test/failure_handler/src/share/conf/linux.properties line 127: > 125: memory.proc_vmstat.delimiter=\0 > 126: memory.thp.app=bash > 127: memory.thp.args=-c\0cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag} I think we should include `shmem_enabled` and we could use `tail` if we want to see what files have what info. But I don't have a strong feeling about that: $ cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag,shmem_enabled} always [madvise] never always defer defer+madvise [madvise] never always within_size advise [never] deny force Versus: $ tail /sys/kernel/mm/transparent_hugepage/{enabled,defrag,shmem_enabled} ==> /sys/kernel/mm/transparent_hugepage/enabled <== always [madvise] never ==> /sys/kernel/mm/transparent_hugepage/defrag <== always defer defer+madvise [madvise] never ==> /sys/kernel/mm/transparent_hugepage/shmem_enabled <== always within_size advise [never] deny force ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3183836877 PR Review Comment: https://git.openjdk.org/jdk/pull/27086#discussion_r2321120030 From stefank at openjdk.org Thu Sep 4 07:49:56 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 07:49:56 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: > I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. > > This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Add shmem_enabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27086/files - new: https://git.openjdk.org/jdk/pull/27086/files/0470c67f..d95e72a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27086&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27086&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27086/head:pull/27086 PR: https://git.openjdk.org/jdk/pull/27086 From stefank at openjdk.org Thu Sep 4 07:49:57 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 07:49:57 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:30:35 GMT, Stefan Johansson wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Add shmem_enabled > > test/failure_handler/src/share/conf/linux.properties line 127: > >> 125: memory.proc_vmstat.delimiter=\0 >> 126: memory.thp.app=bash >> 127: memory.thp.args=-c\0cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag} > > I think we should include `shmem_enabled` and we could use `tail` if we want to see what files have what info. But I don't have a strong feeling about that: > > $ cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag,shmem_enabled} > always [madvise] never > always defer defer+madvise [madvise] never > always within_size advise [never] deny force > > Versus: > > $ tail /sys/kernel/mm/transparent_hugepage/{enabled,defrag,shmem_enabled} > ==> /sys/kernel/mm/transparent_hugepage/enabled <== > always [madvise] never > > ==> /sys/kernel/mm/transparent_hugepage/defrag <== > always defer defer+madvise [madvise] never > > ==> /sys/kernel/mm/transparent_hugepage/shmem_enabled <== > always within_size advise [never] deny force I added shmem_enabled but kept cat for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27086#discussion_r2321156814 From vyazici at openjdk.org Thu Sep 4 07:55:50 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 07:55:50 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> References: <9l-pIuhLga7chfDkPBKvUvPTx8fFcnkY0nkmTTrlI9I=.8e0b36fc-ed36-4699-8531-63b0ba4f8901@github.com> Message-ID: On Thu, 4 Sep 2025 07:19:39 GMT, Alan Bateman wrote: > Can you confirm that the only change from before is the update to src/java.base/share/classes/jdk/internal/foreign/StringSupport.java to deal with the "new" usage there? @AlanBateman, this PR has *one additional change* to deal with the "new" usage in `StringSupport`: 1. f3e7c130391 Revert the revert 2. 3ea1d5ea009 Deal with `StringSupport` 3. b48def1a22d Further simplify sneaky-throws in `String` (via @dfuch) The diff compared to JDK-8356439 (#26413 eea50fbc) is as follows: git diff eea50fbc...b48def1a -- $(git diff --name-only upstream/master | xargs echo) diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java index 8acb8d8514b..54f74266c08 100644 --- a/src/java.base/share/classes/java/lang/String.java +++ b/src/java.base/share/classes/java/lang/String.java @@ -1348,7 +1348,7 @@ private static int malformed4(byte[] src, int sp) { * having to declare the exception */ @SuppressWarnings("unchecked") - private static E malformedInputException(int offset, int length) throws E { + private static E malformedInputException(int offset, int length) { MalformedInputException mie = new MalformedInputException(length); String msg = "malformed input offset : " + offset + ", length : " + length; mie.initCause(new IllegalArgumentException(msg)); @@ -1359,7 +1359,7 @@ private static E malformedInputException(int offset, int l * {@return a new {@link MalformedInputException} for the given malformed * ASCII string} */ - private static MalformedInputException malformedASCII(byte[] val) throws MalformedInputException { + private static MalformedInputException malformedASCII(byte[] val) { int dp = StringCoding.countPositives(val, 0, val.length); return malformedInputException(dp, 1); } @@ -1371,7 +1371,7 @@ private static MalformedInputException malformedASCII(byte[] val) throws Malform * having to declare the exception */ @SuppressWarnings("unchecked") - private static E unmappableCharacterException(int offset) throws E { + private static E unmappableCharacterException(int offset) { UnmappableCharacterException uce = new UnmappableCharacterException(1); String msg = "malformed input offset : " + offset + ", length : 1"; uce.initCause(new IllegalArgumentException(msg, uce)); @@ -1382,7 +1382,7 @@ private static E unmappableCharacterException(int offset) * {@return a new {@link UnmappableCharacterException} for the given * malformed ASCII string} */ - private static UnmappableCharacterException unmappableASCII(byte[] val) throws UnmappableCharacterException { + private static UnmappableCharacterException unmappableASCII(byte[] val) { int dp = StringCoding.countPositives(val, 0, val.length); return unmappableCharacterException(dp); } diff --git a/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java b/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java index 2f842810aa7..bb6cb2d3915 100644 --- a/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java +++ b/src/java.base/share/classes/jdk/internal/foreign/StringSupport.java @@ -73,7 +73,7 @@ private static String readByte(AbstractMemorySegmentImpl segment, long offset, C final byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); @@ -92,7 +92,7 @@ private static String readShort(AbstractMemorySegmentImpl segment, long offset, byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); @@ -111,7 +111,7 @@ private static String readInt(AbstractMemorySegmentImpl segment, long offset, Ch byte[] bytes = new byte[len]; MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len); try { - return JAVA_LANG_ACCESS.uncheckedNewStringNoRepl(bytes, charset); + return JAVA_LANG_ACCESS.uncheckedNewStringOrThrow(bytes, charset); } catch (CharacterCodingException _) { // use replacement characters for malformed input return new String(bytes, charset); ------------- PR Comment: https://git.openjdk.org/jdk/pull/27084#issuecomment-3252376320 From alanb at openjdk.org Thu Sep 4 08:29:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Sep 2025 08:29:42 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: <_KvUNOd7WUsV5u8pgeihu3YQqXtvZQUgGs8ehozlA9o=.ce1be4e2-49cd-4b99-b949-eb4f10269e90@github.com> On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3184023515 From duke at openjdk.org Thu Sep 4 08:45:33 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 4 Sep 2025 08:45:33 GMT Subject: RFR: 8077587: BigInteger Roots [v81] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Small optimization and format comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/a58784d9..51194db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=80 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=79-80 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From aturbanov at openjdk.org Thu Sep 4 09:07:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 09:07:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 src/java.base/share/classes/java/lang/String.java line 691: > 689: } > 690: > 691: /* Is there a reason, why it can't be _converted_ to a proper javadoc? Suggestion: /** src/java.base/share/classes/java/lang/String.java line 797: > 795: * @param cs charset the byte array encoded in > 796: * > 797: * @throws CharacterCodingException for malformed input or unmappable characters Shouldn't we document NPE here too? I mean there is NPE note in `private` method `newStringUTF8OrThrow`, but not in the more widely opened `newStringOrThrow`. That's confusing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321347469 PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321350608 From duke at openjdk.org Thu Sep 4 09:13:44 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 4 Sep 2025 09:13:44 GMT Subject: RFR: 8365467: Issues with jrtfs implementation for exploded run-time images [v2] In-Reply-To: References: Message-ID: <0mSLiEWfvZTqubx4f3dfLjnp_8qyxMl-12kFioI25-4=.627487a2-7571-4cc9-a842-83bb045fa0b0@github.com> On Wed, 3 Sep 2025 17:57:06 GMT, Chen Liang wrote: >> Ah no, there is not, and never was a "getResource()" method on the node class. Nodes are not inner classes and do not have access to the image. >> The getResource() method exists (both now and before my changes) on the ExplocedImage class. >> So I think what I've done here is correct, and no other changes are necessary. > > I think this was the method I saw: https://github.com/openjdk/jdk/blob/1408def0c09c6da9cd1ba2b36a8c25de21f0f193/src/java.base/share/classes/jdk/internal/jimage/ImageReader.java#L572 > It is package private so we cannot override it here. What is it for at all then... It's for getting the location from a Resource node inside the getResource(Node) method. ExplodedImage nodes just don't use ImageLocation at all, so cannot need it. getResource(Node) is overloaded on ExplodedImage and the parent method never called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26757#discussion_r2321371300 From duke at openjdk.org Thu Sep 4 09:16:44 2025 From: duke at openjdk.org (duke) Date: Thu, 4 Sep 2025 09:16:44 GMT Subject: RFR: 8365467: Issues with jrtfs implementation for exploded run-time images [v2] In-Reply-To: <2viHL6KuT_VV5Mrijdf68M2tLJptIvinHW9fZCErqTg=.e2e44843-55a1-4ef3-91e2-4201f2c8698c@github.com> References: <2viHL6KuT_VV5Mrijdf68M2tLJptIvinHW9fZCErqTg=.e2e44843-55a1-4ef3-91e2-4201f2c8698c@github.com> Message-ID: On Fri, 29 Aug 2025 08:49:27 GMT, David Beaumont wrote: >> This PR addresses several issues found while adding unit tests for ExplodedImage. >> I have added review comments for changes (some of which are a little preferential, but bring the code into line with things like ImageReader in terms of the name choices for variables). >> Later it is likely that this code will be adapted for the up-coming preview mode support in Valhalla, so having it unit-testable is important. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Feedback tweaks. @david-beaumont Your change (at version 51a46c8f1358ba958a0c6e4e8622641652674d28) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26757#issuecomment-3252670216 From vyazici at openjdk.org Thu Sep 4 09:41:43 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 09:41:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Improve docs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27084/files - new: https://git.openjdk.org/jdk/pull/27084/files/b48def1a..8d7dcb4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 09:41:45 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 09:41:45 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:01:25 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/java/lang/String.java line 691: > >> 689: } >> 690: >> 691: /* > > Is there a reason, why it can't be _converted_ to a proper javadoc? > Suggestion: > > /** Improved as suggested in 8d7dcb4d410. > src/java.base/share/classes/java/lang/String.java line 797: > >> 795: * @param cs charset the byte array encoded in >> 796: * >> 797: * @throws CharacterCodingException for malformed input or unmappable characters > > Shouldn't we document NPE here too? > I mean there is NPE note in `private` method `newStringUTF8OrThrow`, but not in the more widely opened `newStringOrThrow`. That's confusing. Improved NPE docs in 8d7dcb4d410. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321446143 PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321445517 From aturbanov at openjdk.org Thu Sep 4 09:48:45 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 09:48:45 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:41:43 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Improve docs src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 344: > 342: * @return the newly created string > 343: * @throws CharacterCodingException for malformed or unmappable bytes > 344: * @throws NullPointerException If {@code bytes} is null for `null` cs is also thrown ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321465942 From aturbanov at openjdk.org Thu Sep 4 10:05:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 Sep 2025 10:05:43 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> On Thu, 4 Sep 2025 09:41:43 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Improve docs src/java.base/share/classes/java/lang/String.java line 961: > 959: * @throws CharacterCodingException For malformed input or unmappable characters > 960: */ > 961: static byte[] getBytesUTF8OrThrow(String s) throws CharacterCodingException { `encodeUTF8OrThrow(s.coder(), s.value());` specified to throw `UnmappableCharacterException`. May we should to it here too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321506473 From vyazici at openjdk.org Thu Sep 4 11:22:31 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:22:31 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: More nullability improvements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27084/files - new: https://git.openjdk.org/jdk/pull/27084/files/8d7dcb4d..1852dccc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27084&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27084/head:pull/27084 PR: https://git.openjdk.org/jdk/pull/27084 From vyazici at openjdk.org Thu Sep 4 11:22:32 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:22:32 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 09:45:57 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 344: > >> 342: * @return the newly created string >> 343: * @throws CharacterCodingException for malformed or unmappable bytes >> 344: * @throws NullPointerException If {@code bytes} is null > > for `null` cs is also thrown Fixed in 1852dccc962. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321712147 From vyazici at openjdk.org Thu Sep 4 11:25:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 4 Sep 2025 11:25:53 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v2] In-Reply-To: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> References: <-avSrcF74p9fXQU6etWKeA9APU_h3TqqTt6vMr1YppY=.c9ee2517-ffff-47b4-aaf6-4e5158026a8f@github.com> Message-ID: On Thu, 4 Sep 2025 10:03:10 GMT, Andrey Turbanov wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve docs > > src/java.base/share/classes/java/lang/String.java line 961: > >> 959: * @throws CharacterCodingException For malformed input or unmappable characters >> 960: */ >> 961: static byte[] getBytesUTF8OrThrow(String s) throws CharacterCodingException { > > `encodeUTF8OrThrow(s.coder(), s.value());` specified to throw `UnmappableCharacterException`. May we should to it here too? UCE extends from CCE, hence `throws UCE` is already covered. Plus, what I see from `JLA::*OrThrow` methods, we only declare and document the CCE, not its subclasses. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27084#discussion_r2321722048 From ayang at openjdk.org Thu Sep 4 11:32:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 11:32:49 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: <8bginA83--2TrOIMPDkbET4WT1QrMUgzn_r6IrUkDaA=.0a95c192-750b-4a3e-8fd7-05e6fb856d9c@github.com> On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3184726590 From dmlloyd at openjdk.org Thu Sep 4 12:30:44 2025 From: dmlloyd at openjdk.org (David Lloyd) Date: Thu, 4 Sep 2025 12:30:44 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v6] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 21:38:14 GMT, Roger Riggs wrote: > `DestroyForcibly` is an escalation that should only be used with a known poorly behaved process; and that's up to the programmer. It is the equivalent of `kill -9`. It should not be used in the normal case. Unfortunately, Windows does not have a polite, please terminate API so `destroy` has the same behavior as `destroyForcibly`. This is my point exactly; the behavior will differ between Windows and non-Windows. (I didn't want to name-and-shame any particular OS though.) :-) > If the caller uses `process.waitFor()` within the try-catch, the process will have terminated, possibly based on the stream closings, and `destroy()` will not be called. If emphasis is needed, the javadoc can elaborate. OK. Clarifying in the javadoc would be option three then (the other two options being the two ways mentioned to make the behavior equitable between platforms). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2321933225 From shade at openjdk.org Thu Sep 4 13:20:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 4 Sep 2025 13:20:50 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3185246018 From rriggs at openjdk.org Thu Sep 4 13:22:00 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 13:22:00 GMT Subject: RFR: 8365467: Issues with jrtfs implementation for exploded run-time images [v2] In-Reply-To: <2viHL6KuT_VV5Mrijdf68M2tLJptIvinHW9fZCErqTg=.e2e44843-55a1-4ef3-91e2-4201f2c8698c@github.com> References: <2viHL6KuT_VV5Mrijdf68M2tLJptIvinHW9fZCErqTg=.e2e44843-55a1-4ef3-91e2-4201f2c8698c@github.com> Message-ID: On Fri, 29 Aug 2025 08:49:27 GMT, David Beaumont wrote: >> This PR addresses several issues found while adding unit tests for ExplodedImage. >> I have added review comments for changes (some of which are a little preferential, but bring the code into line with things like ImageReader in terms of the name choices for variables). >> Later it is likely that this code will be adapted for the up-coming preview mode support in Valhalla, so having it unit-testable is important. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Feedback tweaks. Thanks for the refactoring and cleanup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26757#issuecomment-3253678184 From duke at openjdk.org Thu Sep 4 13:22:01 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 4 Sep 2025 13:22:01 GMT Subject: Integrated: 8365467: Issues with jrtfs implementation for exploded run-time images In-Reply-To: References: Message-ID: <4EwVdy1IXwLRtqzKtXhx2d0QfmcWKgzJ4MB85X9xyyU=.00f61653-6542-40d8-91f4-56bc80930054@github.com> On Wed, 13 Aug 2025 12:20:23 GMT, David Beaumont wrote: > This PR addresses several issues found while adding unit tests for ExplodedImage. > I have added review comments for changes (some of which are a little preferential, but bring the code into line with things like ImageReader in terms of the name choices for variables). > Later it is likely that this code will be adapted for the up-coming preview mode support in Valhalla, so having it unit-testable is important. This pull request has now been integrated. Changeset: e1903557 Author: David Beaumont Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/e19035577724f40aca14ef7d5dad0906ce9e89ab Stats: 383 lines in 5 files changed: 297 ins; 28 del; 58 mod 8365467: Issues with jrtfs implementation for exploded run-time images Reviewed-by: rriggs, sundar ------------- PR: https://git.openjdk.org/jdk/pull/26757 From ghan at openjdk.org Thu Sep 4 13:22:08 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 4 Sep 2025 13:22:08 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v13] In-Reply-To: References: Message-ID: > Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - move common method into a common file. - Merge remote-tracking branch 'upstream/master' into 8328874 - Update Class.java change overflow check - Update Class.java Simplify length check - Update Class.java avoid the case of int overflow - Update Class.java Use ModifiedUtf.utfLen instead of static import for readability - change copyright year - a small fix - add regression test - Merge remote-tracking branch 'upstream/master' into 8328874 - ... and 6 more: https://git.openjdk.org/jdk/compare/a30799ba...edc1694d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26802/files - new: https://git.openjdk.org/jdk/pull/26802/files/9c580f0d..edc1694d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=11-12 Stats: 22075 lines in 1027 files changed: 15508 ins; 3161 del; 3406 mod Patch: https://git.openjdk.org/jdk/pull/26802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802 PR: https://git.openjdk.org/jdk/pull/26802 From rriggs at openjdk.org Thu Sep 4 13:31:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 13:31:47 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:22:31 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > More nullability improvements Good to go! ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3185310732 From dfuchs at openjdk.org Thu Sep 4 14:06:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 4 Sep 2025 14:06:52 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v16] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 653 commits: - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - Simplify control flow - Remove unnecessary instanceof checks - Use IntFunction for header generator - merge latest changes from master branch - http3: minor cleanup - http3: cleanup - QuicConnectionImpl::maxInitialTimer should be volatile - ... and 643 more: https://git.openjdk.org/jdk/compare/a40afdd0...3925afda ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=15 Stats: 105850 lines in 474 files changed: 103019 ins; 1333 del; 1498 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From djelinski at openjdk.org Thu Sep 4 14:16:03 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 4 Sep 2025 14:16:03 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v16] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:06:52 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 653 commits: > > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - merge latest changes from master branch > - http3: minor cleanup > - http3: cleanup - QuicConnectionImpl::maxInitialTimer should be volatile > - ... and 643 more: https://git.openjdk.org/jdk/compare/a40afdd0...3925afda Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3185555986 From liach at openjdk.org Thu Sep 4 14:45:48 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 14:45:48 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v13] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 13:22:08 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - move common method into a common file. > - Merge remote-tracking branch 'upstream/master' into 8328874 > - Update Class.java > > change overflow check > - Update Class.java > > Simplify length check > - Update Class.java > > avoid the case of int overflow > - Update Class.java > > Use ModifiedUtf.utfLen instead of static import for readability > - change copyright year > - a small fix > - add regression test > - Merge remote-tracking branch 'upstream/master' into 8328874 > - ... and 6 more: https://git.openjdk.org/jdk/compare/829295d7...edc1694d src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 37: > 35: public abstract class ModifiedUtf { > 36: //Max length in Modified UTF-8 bytes for class names.(see max_symbol_length in symbol.hpp) > 37: public static final int JAVA_CLASSNAME_MAX_LEN = 65535; max_symbol_length is not just class names - it is presumably the limit for modified UTF-8, as seen in `java.io.DataOutput::writeUTF`. We can just use a more generic name like `MAX_ENCODED_LENGTH`. src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 80: > 78: */ > 79: @ForceInline > 80: public static boolean classNameLengthIsValid(String name) { This can be reused by `DataOutput` too, so maybe just `isEncodable` src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 87: > 85: return true; > 86: } > 87: // Check exact Modified UTF-8 length. Before doing that, I recommend another fast path `if (nameLen > MAX_LEN) return false`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2322427947 PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2322433506 PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2322433856 From liach at openjdk.org Thu Sep 4 15:05:46 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 15:05:46 GMT Subject: RFR: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:22:31 GMT, Volkan Yazici wrote: >> [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. >> >> [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 >> [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 >> [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > More nullability improvements Looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27084#pullrequestreview-3185780567 From tschatzl at openjdk.org Thu Sep 4 15:08:53 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 4 Sep 2025 15:08:53 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v53] In-Reply-To: References: Message-ID: <-6I6w_xqk0J13gqMX8ZQel4elME1K0ZYs55Li2lmgd8=.fdd1d6fb-eaae-4d93-a2ac-74b03d3f4212@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 61 more: https://git.openjdk.org/jdk/compare/e1903557...2a614a2c ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=52 Stats: 7117 lines in 112 files changed: 2592 ins; 3585 del; 940 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From ghan at openjdk.org Thu Sep 4 15:57:48 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 4 Sep 2025 15:57:48 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v13] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:42:33 GMT, Chen Liang wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: >> >> - move common method into a common file. >> - Merge remote-tracking branch 'upstream/master' into 8328874 >> - Update Class.java >> >> change overflow check >> - Update Class.java >> >> Simplify length check >> - Update Class.java >> >> avoid the case of int overflow >> - Update Class.java >> >> Use ModifiedUtf.utfLen instead of static import for readability >> - change copyright year >> - a small fix >> - add regression test >> - Merge remote-tracking branch 'upstream/master' into 8328874 >> - ... and 6 more: https://git.openjdk.org/jdk/compare/ddf5e10b...edc1694d > > src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 80: > >> 78: */ >> 79: @ForceInline >> 80: public static boolean classNameLengthIsValid(String name) { > > This can be reused by `DataOutput` too, so maybe just `isEncodable` @liach This only checks the encoded length rather than full encodability ? would a name like isValidLen be more accurate? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2322650439 From ghan at openjdk.org Thu Sep 4 16:03:47 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 4 Sep 2025 16:03:47 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v13] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:42:40 GMT, Chen Liang wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: >> >> - move common method into a common file. >> - Merge remote-tracking branch 'upstream/master' into 8328874 >> - Update Class.java >> >> change overflow check >> - Update Class.java >> >> Simplify length check >> - Update Class.java >> >> avoid the case of int overflow >> - Update Class.java >> >> Use ModifiedUtf.utfLen instead of static import for readability >> - change copyright year >> - a small fix >> - add regression test >> - Merge remote-tracking branch 'upstream/master' into 8328874 >> - ... and 6 more: https://git.openjdk.org/jdk/compare/edb7a478...edc1694d > > src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 87: > >> 85: return true; >> 86: } >> 87: // Check exact Modified UTF-8 length. > > Before doing that, I recommend another fast path `if (nameLen > MAX_LEN) return false`. @liach I was thinking whether it might be better to place **if (nameLen > MAX_LEN) return false** after the **if (nameLen <= MAX_LEN / 3) return true** check, since in most cases nameLen will be smaller than MAX_LEN / 3 and this order would optimize for the common case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2322673732 From headius at headius.com Thu Sep 4 16:41:57 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 4 Sep 2025 11:41:57 -0500 Subject: MethodHandles.lookup errors where publicLookup is ok In-Reply-To: <6bb9f1ec-4c1b-4893-8751-0c72da940877@oracle.com> References: <76593135-89db-41ef-a493-5dd60e873e09@oracle.com> <6bb9f1ec-4c1b-4893-8751-0c72da940877@oracle.com> Message-ID: On Wed, Sep 3, 2025 at 4:09?AM Alan Bateman wrote: > Method handles are aligned with bytecode behavior, this includes access > checks in the MH factory methods. If you were to inject code into module > org.jruby.dist with a reference to a class in module X then any attempt in > org.jruby.dist to access a class in module X would fail with > IllegalAccessError. org.jruby.dist's module does not declare "requires X" > and so org.jruby.dist does not read X. > > Lookup.publicLookup is the minimally trusted lookup to create method > handles to public fields and methods. This necessitated the addition of the > UNCONDITIONAL access mode even though it doesn't correspond to a modifier > in the access flags. It means that the access check done with the > publicLookup is closer to what you see with core reflection (where > readability is assumed) rather than bytecode. This may seem complicated but > it's not something that most developers will ever need to deal with > directly. > Ok, I understand. Play with sharp tools, get cut. And given the evolution of MH and Lookup over the years I'm not surprised my original expectations from a decade ago don't quite match the modern reality of JPMS. > Raising an error saying it "is not accessible" is also rather misleading > when it actually **is** accessible > > It's not accessible from code in module org.jruby.dist so not accessible > with the Lookup obtained from lookup(). That said, we need to improve the > IAE exception messages. A lot of effort went into exception messages thrown > by setAccessible/Method.invoke/Field.xxx where as the IAE exception > messages thrown by the MH factory methods are less helpful. > I guess it will just take me some time to internalize the reality of "can't be read until read access is requested" for cases that "magically" work through traditional reflection. This discussion helps. BTW: Your first message has "symbolic reference class is not accessible: > class jdk.proxy4.$Proxy49" which suggests that the JRuby code may be > attempting the findVirtual for the method in the proxy implementation class > rather than the method in the interface class. You might to check that. > Fair point. We have typically assumed that if Modifier.isPublic(klass) was true, we are good to go ahead and bind that class and its methods in our Java integration layer and indy call sites. I'm testing a patch that adds JRUBY_MODULE.canRead(klass.getModule()) to that requirement and so far it fixes the original issue and does not appear to regress any other features. Instead of binding Function.apply as Proxy49.apply, we should only bind it against the public interface. - Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Thu Sep 4 17:09:46 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 17:09:46 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v13] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:54:38 GMT, Guanqiang Han wrote: >> src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 80: >> >>> 78: */ >>> 79: @ForceInline >>> 80: public static boolean classNameLengthIsValid(String name) { >> >> This can be reused by `DataOutput` too, so maybe just `isEncodable` > > @liach This only checks the encoded length rather than full encodability ? would a name like isValidLen be more accurate? Sure, we can go with that name! >> src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 87: >> >>> 85: return true; >>> 86: } >>> 87: // Check exact Modified UTF-8 length. >> >> Before doing that, I recommend another fast path `if (nameLen > MAX_LEN) return false`. > > @liach I was thinking whether it might be better to place **if (nameLen > MAX_LEN) return false** after the **if (nameLen <= MAX_LEN / 3) return true** check, since in most cases nameLen will be smaller than MAX_LEN / 3 and this order would optimize for the common case. Yep, this is after the true check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2322832084 PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2322832768 From liach at openjdk.org Thu Sep 4 17:17:58 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 17:17:58 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v3] In-Reply-To: References: Message-ID: > java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. > > Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". > > However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. > > To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: More ioi review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27010/files - new: https://git.openjdk.org/jdk/pull/27010/files/d65a56a2..fa581ff3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27010&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27010&range=01-02 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27010.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27010/head:pull/27010 PR: https://git.openjdk.org/jdk/pull/27010 From chen.l.liang at oracle.com Thu Sep 4 17:35:17 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 4 Sep 2025 17:35:17 +0000 Subject: MethodHandles.lookup errors where publicLookup is ok In-Reply-To: References: <76593135-89db-41ef-a493-5dd60e873e09@oracle.com> <6bb9f1ec-4c1b-4893-8751-0c72da940877@oracle.com> Message-ID: Just curious, would klass.getModule().isExported(klass.getPackageName(), JRUBY_MODULE) be a more accurate test here? Chen ________________________________ From: core-libs-dev on behalf of Charles Oliver Nutter Sent: Thursday, September 4, 2025 11:41 AM To: Alan Bateman Cc: core-libs-dev at openjdk.org Subject: Re: MethodHandles.lookup errors where publicLookup is ok On Wed, Sep 3, 2025 at 4:09?AM Alan Bateman > wrote: Method handles are aligned with bytecode behavior, this includes access checks in the MH factory methods. If you were to inject code into module org.jruby.dist with a reference to a class in module X then any attempt in org.jruby.dist to access a class in module X would fail with IllegalAccessError. org.jruby.dist's module does not declare "requires X" and so org.jruby.dist does not read X. Lookup.publicLookup is the minimally trusted lookup to create method handles to public fields and methods. This necessitated the addition of the UNCONDITIONAL access mode even though it doesn't correspond to a modifier in the access flags. It means that the access check done with the publicLookup is closer to what you see with core reflection (where readability is assumed) rather than bytecode. This may seem complicated but it's not something that most developers will ever need to deal with directly. Ok, I understand. Play with sharp tools, get cut. And given the evolution of MH and Lookup over the years I'm not surprised my original expectations from a decade ago don't quite match the modern reality of JPMS. Raising an error saying it "is not accessible" is also rather misleading when it actually **is** accessible It's not accessible from code in module org.jruby.dist so not accessible with the Lookup obtained from lookup(). That said, we need to improve the IAE exception messages. A lot of effort went into exception messages thrown by setAccessible/Method.invoke/Field.xxx where as the IAE exception messages thrown by the MH factory methods are less helpful. I guess it will just take me some time to internalize the reality of "can't be read until read access is requested" for cases that "magically" work through traditional reflection. This discussion helps. BTW: Your first message has "symbolic reference class is not accessible: class jdk.proxy4.$Proxy49" which suggests that the JRuby code may be attempting the findVirtual for the method in the proxy implementation class rather than the method in the interface class. You might to check that. Fair point. We have typically assumed that if Modifier.isPublic(klass) was true, we are good to go ahead and bind that class and its methods in our Java integration layer and indy call sites. I'm testing a patch that adds JRUBY_MODULE.canRead(klass.getModule()) to that requirement and so far it fixes the original issue and does not appear to regress any other features. Instead of binding Function.apply as Proxy49.apply, we should only bind it against the public interface. - Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From matsaave at openjdk.org Thu Sep 4 18:07:53 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 4 Sep 2025 18:07:53 GMT Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed Message-ID: The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests. ------------- Commit messages: - Removed unused methods and declarations - 8364660: ClassVerifier::ends_in_athrow() should be removed Changes: https://git.openjdk.org/jdk/pull/27107/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27107&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364660 Stats: 250 lines in 3 files changed: 0 ins; 250 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27107.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27107/head:pull/27107 PR: https://git.openjdk.org/jdk/pull/27107 From jvernee at openjdk.org Thu Sep 4 18:10:43 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 4 Sep 2025 18:10:43 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 17:17:58 GMT, Chen Liang wrote: >> java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. >> >> Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". >> >> However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. >> >> To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > More ioi review Thanks for improving the documentation! I've left a few suggestions inline. src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java line 46: > 44: /// arguments for currying. > 45: /// > 46: /// Each BMH acts like a strongly-typed argument list, where the types are What do you mean with 'strongly-typed argument list'? Bound method handles are not just used for arguments. I'd described BMH as method handles with a number of extra fields that can be referenced from its lambda form. src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 205: > 203: /// > 204: /// The method names of this class are internal tokens recognized by > 205: /// [InvokerBytecodeGenerator#lookupPregenerated] and is subject to change. Suggestion: /// [InvokerBytecodeGenerator#lookupPregenerated] and are subject to change. src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 58: > 56: /// > 57: /// Since lambda forms and bound method handle species are closely tied to > 58: /// method types, which have many varieties, this generator needs *traces* to Since this is the first mention of 'traces' in this file, I think it would be great if you could explain what they are, how they are generated (with the system properties), and what their format are (probably just a link to the right methods where the printing happens). src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 100: > 98: /// > ``` > 99: /// > javap -c -p -v java.lang.invoke.LambdaForm\$Holder > 100: /// > ``` I think it is probably enough to put this comment on `javap` here, and it doesn't need to be on all the holder classes, since the comment there already links here. ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27010#pullrequestreview-3186456503 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2322985931 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2322987321 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2323028010 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2323013426 From jvernee at openjdk.org Thu Sep 4 18:10:44 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 4 Sep 2025 18:10:44 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 17:56:43 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> More ioi review > > src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 205: > >> 203: /// >> 204: /// The method names of this class are internal tokens recognized by >> 205: /// [InvokerBytecodeGenerator#lookupPregenerated] and is subject to change. > > Suggestion: > > /// [InvokerBytecodeGenerator#lookupPregenerated] and are subject to change. Same elsewhere ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2322990674 From rriggs at openjdk.org Thu Sep 4 18:22:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 18:22:47 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v13] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:40:36 GMT, Chen Liang wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: >> >> - move common method into a common file. >> - Merge remote-tracking branch 'upstream/master' into 8328874 >> - Update Class.java >> >> change overflow check >> - Update Class.java >> >> Simplify length check >> - Update Class.java >> >> avoid the case of int overflow >> - Update Class.java >> >> Use ModifiedUtf.utfLen instead of static import for readability >> - change copyright year >> - a small fix >> - add regression test >> - Merge remote-tracking branch 'upstream/master' into 8328874 >> - ... and 6 more: https://git.openjdk.org/jdk/compare/7a4c9817...edc1694d > > src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 37: > >> 35: public abstract class ModifiedUtf { >> 36: //Max length in Modified UTF-8 bytes for class names.(see max_symbol_length in symbol.hpp) >> 37: public static final int JAVA_CLASSNAME_MAX_LEN = 65535; > > max_symbol_length is not just class names - it is presumably the limit for modified UTF-8, as seen in `java.io.DataOutput::writeUTF`. We can just use a more generic name like `MAX_ENCODED_LENGTH`. There is no maximum length of an encoded UTF-8 string. The "modified UTF-8" is modified because it encodes a zero byte using the 2-byte version so the result never contains a null. Allowing in some use cases to terminated the encoded UTF-8 bytes using a nul byte. In the DataOutput case, it was desirable to provide the length of the encoded bytes to make it easy to read or skip the encoded UTF-8. It improved some stream decoding but increased the cost of writing because the encoded length was needed before writing. It also prevented an exact size allocation before decoding. In retrospect, it could have provided both the encoded and decoded lengths, saving some allocations. In ObjectOutputStream, the stream protocol had both long and short forms because Strings can be much longer. The method names and constants are specific to the encoding of **Class** names and that should be reflected in their names. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2323069496 From matsaave at openjdk.org Thu Sep 4 18:24:57 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 4 Sep 2025 18:24:57 GMT Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed [v2] In-Reply-To: References: Message-ID: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> > The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Fixed copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27107/files - new: https://git.openjdk.org/jdk/pull/27107/files/57003c7f..7b54a9f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27107&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27107&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27107.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27107/head:pull/27107 PR: https://git.openjdk.org/jdk/pull/27107 From liach at openjdk.org Thu Sep 4 18:32:44 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 18:32:44 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v13] In-Reply-To: References: Message-ID: <-yMAtcy2ffpx0SpK7dobHQio87QZdjHLoUijC7yQ9qI=.eae22e7a-9b4a-4c48-89db-320800e0f572@github.com> On Thu, 4 Sep 2025 18:19:40 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 37: >> >>> 35: public abstract class ModifiedUtf { >>> 36: //Max length in Modified UTF-8 bytes for class names.(see max_symbol_length in symbol.hpp) >>> 37: public static final int JAVA_CLASSNAME_MAX_LEN = 65535; >> >> max_symbol_length is not just class names - it is presumably the limit for modified UTF-8, as seen in `java.io.DataOutput::writeUTF`. We can just use a more generic name like `MAX_ENCODED_LENGTH`. > > There is no maximum length of an encoded UTF-8 string. The "modified UTF-8" is modified because it encodes a zero byte using the 2-byte version so the result never contains a null. Allowing in some use cases to terminated the encoded UTF-8 bytes using a nul byte. > In the DataOutput case, it was desirable to provide the length of the encoded bytes to make it easy to read or skip the encoded UTF-8. It improved some stream decoding but increased the cost of writing because the encoded length was needed before writing. It also prevented an exact size allocation before decoding. In retrospect, it could have provided both the encoded and decoded lengths, saving some allocations. > In ObjectOutputStream, the stream protocol had both long and short forms because Strings can be much longer. > The method names and constants are specific to the encoding of **Class** names and that should be reflected in their names. These are specific to the encoding of all UTF-8 Class File constant too, instead of being Class specific. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2323100636 From rriggs at openjdk.org Thu Sep 4 18:38:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 18:38:46 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v13] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 13:22:08 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - move common method into a common file. > - Merge remote-tracking branch 'upstream/master' into 8328874 > - Update Class.java > > change overflow check > - Update Class.java > > Simplify length check > - Update Class.java > > avoid the case of int overflow > - Update Class.java > > Use ModifiedUtf.utfLen instead of static import for readability > - change copyright year > - a small fix > - add regression test > - Merge remote-tracking branch 'upstream/master' into 8328874 > - ... and 6 more: https://git.openjdk.org/jdk/compare/248089f6...edc1694d test/jdk/java/lang/Class/forName/ForNameNames.java line 97: > 95: void testTooLongName() { > 96: ClassLoader loader = ForNameNames.class.getClassLoader(); > 97: String tooLongName = "A".repeat(JAVA_CLASSNAME_MAX_LEN+1); Its would be good to test strings at each of the boundary conditions and each of the encoded lengths. 1-byte, 2-byte, and 3 byte forms at the MAX_LEN-1, MAX_LEN, MAX_LEN+1, and less than, equal, and more than MAX_LEN/3. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2323117857 From shade at openjdk.org Thu Sep 4 18:47:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 4 Sep 2025 18:47:28 GMT Subject: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 Message-ID: GetStackTraceALotWhenPinned test times out every so often in GHA. The last sightings are on macos-aarch64: 2025-09-04T10:41:29.357879Z => 87894 of 100000 2025-09-04T10:41:30.365534Z => 88105 of 100000 Timeout signalled after 300 seconds 2025-09-04T10:41:31.367068Z => 88298 of 100000 2025-09-04T10:41:32.377128Z => 88400 of 100000 2025-09-03T10:08:37.713537Z => 74715 of 100000 2025-09-03T10:08:38.717750Z => 74818 of 100000 Timeout signalled after 300 seconds 2025-09-03T10:08:39.722960Z => 74922 of 100000 2025-09-03T10:08:40.726642Z => 75024 of 100000 Looks like we are nearly there, just need fewer iterations. I think like with [JDK-8344577](https://bugs.openjdk.org/browse/JDK-8344577), we just need to extend the test check for AArch64 macs as well. Additional testing: - [x] MacOS AArch64 server fastdebug, `java/lang/Thread/virtual/stress`, 10x ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/27104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366893 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27104/head:pull/27104 PR: https://git.openjdk.org/jdk/pull/27104 From rriggs at openjdk.org Thu Sep 4 21:25:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 21:25:52 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v12] In-Reply-To: References: <0aWMgDcLLb77dhbIH-gZgRyxjBS0xi9Rt9XvrPSqXqU=.aed892d2-e248-42f7-aa6a-948e2ed65151@github.com> Message-ID: On Thu, 3 Jul 2025 09:53:30 GMT, Kieran Farrell wrote: >> src/java.base/share/classes/java/util/UUID.java line 212: >> >>> 210: * @since 26 >>> 211: */ >>> 212: public static UUID unixEpochTimeMillis() { >> >> Is there a list anywhere on the names that have been discussed already? Asking because the existing static factory method for a type 4 is randomUUID(). Also, there are several methods (esp. in java.time) that use "Epoch" in method names name rather than "Unix Epoch". Also if you rename the timestamp parameter to something that includes "millis" in the name then it would help usage in IDEs where it's more obvious at the use-site that the parameter is in millis. > > The original proposed name was `timestampUUID` but it was decided against to avoid confusion with UUID-v1, which is also time-based, there hasnt been much discussion beyond that. Maybe something like `epochMilliUUID()` would better follow the naming conventions? > > Reagarding the parameter, updating to something like `epochMillis` or `timestampMillis` would make sense. The `UUID.epochMillis()` and `UUID.epochMillis(long timestamp)` is concise and identifies both the Unix Epoch and the granularity of millis. (Sorry for the long absence from this thread). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2323539314 From rriggs at openjdk.org Thu Sep 4 21:26:27 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 21:26:27 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3] In-Reply-To: References: Message-ID: <3TW1CAh7knqlQxMbAS-WXYKSxDrJiOcrJ9A7F-JaeQQ=.3bb5e9b0-a031-4753-9545-7031b91d3db4@github.com> On Tue, 20 May 2025 19:25:13 GMT, Philippe Marschall wrote: >> Kieran Farrell has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > src/java.base/share/classes/java/util/UUID.java line 242: > >> 240: ns['C'] = 12; >> 241: ns['D'] = 13; >> 242: ns['E'] = 14; > > It's a bit unfortunate that `SecureRandom#nextBytes(byte[])` does not allow us to pass an offset and length. Here we generate 16 bytes of random data but throw the first 8 bytes away. In the meantime, `SecureRandom.nextLong()` has been implemented. Composing the two longs from the timestamp and the random will take fewer lines of code. 8357915: SecureRandom nextLong memory usage ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2323556652 From rriggs at openjdk.org Thu Sep 4 21:27:08 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 21:27:08 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v13] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 08:47:20 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > update note to @api note test/jdk/java/util/UUID/UUIDTest.java line 52: > 50: unixEpochTimeMillisTest(); > 51: unixEpochTimeMillisTest_Multi(); > 52: unixEpochTimeMillis_userInputTest(); Also rename the tests to use the `epochMillis` naming. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2323570161 From scolebourne at joda.org Thu Sep 4 21:32:30 2025 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 4 Sep 2025 22:32:30 +0100 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: The best reason for adding MAX (max positive) and MIN (max negative) is that the alternative is digging around in the Javadoc to figure it out, and probably getting it wrong. It also provides a great place to document the usage issues, which are no different to Long.MAX_VALUE or Instant.MAX. Which is the bigger point here - MAX/MIN values are *always* weird, and I really wouldn't overthink this. I understand the appeal of a BIG value, but it is a domain specific thing and not for the JDK in my view. Stephen On Thu, 4 Sept 2025 at 02:33, Roger Riggs wrote: > > Hi, > > I'd be interested in the range of use cases for Duration.MAX or MIN. > > But for deadlines, I think the code should compute the deadline from a Duration of its choice based on the use. > Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores information about the particular use that is relevant. Its just sloppy code that doesn't bother to express how long is long enough to meet operational parameters. > > YMMV, Roger > > On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: > > Duration.MIN is a whole 'nother bag of worms, because Durations are signed (they can be positive or negative...or zero). Internally we also have Durations.MIN, but it's not public ... and along with it, I left myself a helpful note about naming: > > /** The minimum supported {@code Duration}, approximately -292 billion years. */ > // Note: before making this constant public, consider that "MIN" might not be a great name (not > // everyone knows that Durations can be negative!). > static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); > > This reminds me of Double.MIN_VALUE (which is the smallest _positive_ double value) --- we've seen Double.MIN_VALUE misused so much that we introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large percent of Double.MIN_VALUE users actually want the smallest possible negative value, aka -Double.MAX_VALUE. > > If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE). > > On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: >> >> If you ask me, I don?t find it very useful, It won?t work for arithmetrics, even the APIs would have a hard time using it (how do you express the deadline) and APIs with a timeout parameter do have a good reason for it, better pick ?possible? values for better self healing and unstuck of systems. In fact I would err on the smaller side in combination with expecting spurious wakeups. >> >> BTW, when you introduce MIN as well, maybe also think about min precision, min delta or such. Will it always be 1 nano? >> >> Gru?, >> Bernd >> -- >> https://bernd.eckenfels.net >> ________________________________ >> Von: core-libs-dev im Auftrag von Pavel Rappo >> Gesendet: Donnerstag, September 4, 2025 12:41 AM >> An: Kurt Alfred Kluever >> Cc: Stephen Colebourne ; core-libs-dev >> Betreff: Re: Duration.MAX_VALUE >> >> This is useful; thanks. It would be good to see more of your data. >> >> My use case is also duration which practically means **forever**. I >> pass it to methods that accept timeouts, and expect these methods to >> correctly interpret it. >> >> One example of a practical interpretation is >> java.util.concurrent.TimeUnit.convert(Duration). This method never >> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is >> roughly 292 years. >> >> Would I be okay, if the proposed duration didn't reflect **forever** >> but instead reflected **long enough**? I think so. But it still >> somehow feels wrong to make it less than maximum representable value. >> >> Personally, I'm not interested in calendar arithmetic, that is, in >> adding or subtracting durations. Others might be, and that's okay and >> needs to be factored in. For better or worse, java.time made a choice >> to be unforgiving in regard to overflow and is very upfront about it. >> It's not only proposed Duration.MAX. The same thing happens if you try >> this >> >> Instant.MAX.toEpochMilli() >> >> I guess my point is that doing calendar arithmetic on an unknown value >> is probably wrong. Doing it on a known huge/edge-case value is surely >> wrong. So back to your data. I would be interested to see what >> triggers overflows for your Durations.MAX. >> >> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever wrote: >> > >> > Hi all, >> > >> > Internally at Google, we've had a Durations.MAX constant exposed for the past 7 years. It now has about 700 usages across our depot, which I can try to categorize (at a future date). >> > >> > While I haven't performed that analysis yet, I think exposing this constant was a bit of a mistake. People seem to want to use MAX to mean "forever" (often in regards to an RPC deadline). This works fine as long as every single layer that touches the deadline is very careful about overflow. The only reasonable thing you can do with MAX is compareTo() and equals(). Attempting to do any simple math operation (e.g., now+deadline) is going to explode. Additionally, decomposing Duration.MAX explodes for any sub-second precision (e.g., toMillis()). >> > >> > As we dug into this, another proposal came up which was something like Durations.VERY_LONG. This duration would be longer than any reasonable finite duration but not long enough to cause an overflow when added to any reasonable time. E.g., a million years would probably satisfy both criteria. This would mean math operations and decompositions won't explode (well, microseconds and nanoseconds still would), and it could safely be used as a relative timeout. >> > >> > As I mentioned above, I'd be happy to try to categorize a sample of our 700 existing usages if folks think that would be useful for this proposal. >> > >> > Thanks, >> > >> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem team) >> > >> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo wrote: >> >> >> >> If I understood you correctly, you think we should also add >> >> Duration.MIN. If so, what use case do you envision for it? Or we add >> >> if purely for symmetry with Instant? >> >> >> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo wrote: >> >> > >> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne wrote: >> >> > > >> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! >> >> > > The constants would be MAX/MIN as per classes like Instant. >> >> > > Stephen >> >> > >> >> > I thought that naming could be tricky :) The public constant >> >> > Duration.ZERO and the public method isZero() are already there. >> >> > However, it does not preclude us from naming a new constant MAX. >> > >> > >> > >> > -- >> > kak >> > > > -- > kak > > From kevin.bourrillion at oracle.com Thu Sep 4 21:56:30 2025 From: kevin.bourrillion at oracle.com (Kevin Bourrillion) Date: Thu, 4 Sep 2025 21:56:30 +0000 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: From the peanut gallery, in case it is helpful. > MAX/MIN values are *always* weird, and I really wouldn't overthink this. Well, if Kurt?s willing to analyze a sample of those 700 usages to understand what they?re really trying to do, I think we can have a smarter discussion with that info in hand, and this wouldn?t seem like overthinking to me. And? I?m not sure why we started talking about MIN in the same breath. It didn?t seem to be motivated by use cases or arguments of real-world benefit, and imho, symmetry alone shouldn?t suffice as justification. Plus I have a particular concern; I think many users have never quite realized that durations can be negative, and will misunderstand what `MIN` is when they see it. We might make the exact inverse mistake as with Double.MIN_VALUE? From: core-libs-dev on behalf of Stephen Colebourne Date: Thursday, September 4, 2025 at 2:33?PM To: core-libs-dev at openjdk.org Subject: Re: Duration.MAX_VALUE The best reason for adding MAX (max positive) and MIN (max negative) is that the alternative is digging around in the Javadoc to figure it out, and probably getting it wrong. It also provides a great place to document the usage issues, which are no different to Long.MAX_VALUE or Instant.MAX. Which is the bigger point here - MAX/MIN values are *always* weird, and I really wouldn't overthink this. I understand the appeal of a BIG value, but it is a domain specific thing and not for the JDK in my view. Stephen On Thu, 4 Sept 2025 at 02:33, Roger Riggs wrote: > > Hi, > > I'd be interested in the range of use cases for Duration.MAX or MIN. > > But for deadlines, I think the code should compute the deadline from a Duration of its choice based on the use. > Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores information about the particular use that is relevant. Its just sloppy code that doesn't bother to express how long is long enough to meet operational parameters. > > YMMV, Roger > > On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: > > Duration.MIN is a whole 'nother bag of worms, because Durations are signed (they can be positive or negative...or zero). Internally we also have Durations.MIN, but it's not public ... and along with it, I left myself a helpful note about naming: > > /** The minimum supported {@code Duration}, approximately -292 billion years. */ > // Note: before making this constant public, consider that "MIN" might not be a great name (not > // everyone knows that Durations can be negative!). > static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); > > This reminds me of Double.MIN_VALUE (which is the smallest _positive_ double value) --- we've seen Double.MIN_VALUE misused so much that we introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large percent of Double.MIN_VALUE users actually want the smallest possible negative value, aka -Double.MAX_VALUE. > > If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE). > > On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: >> >> If you ask me, I don?t find it very useful, It won?t work for arithmetrics, even the APIs would have a hard time using it (how do you express the deadline) and APIs with a timeout parameter do have a good reason for it, better pick ?possible? values for better self healing and unstuck of systems. In fact I would err on the smaller side in combination with expecting spurious wakeups. >> >> BTW, when you introduce MIN as well, maybe also think about min precision, min delta or such. Will it always be 1 nano? >> >> Gru?, >> Bernd >> -- >> https://bernd.eckenfels.net >> ________________________________ >> Von: core-libs-dev im Auftrag von Pavel Rappo >> Gesendet: Donnerstag, September 4, 2025 12:41 AM >> An: Kurt Alfred Kluever >> Cc: Stephen Colebourne ; core-libs-dev >> Betreff: Re: Duration.MAX_VALUE >> >> This is useful; thanks. It would be good to see more of your data. >> >> My use case is also duration which practically means **forever**. I >> pass it to methods that accept timeouts, and expect these methods to >> correctly interpret it. >> >> One example of a practical interpretation is >> java.util.concurrent.TimeUnit.convert(Duration). This method never >> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is >> roughly 292 years. >> >> Would I be okay, if the proposed duration didn't reflect **forever** >> but instead reflected **long enough**? I think so. But it still >> somehow feels wrong to make it less than maximum representable value. >> >> Personally, I'm not interested in calendar arithmetic, that is, in >> adding or subtracting durations. Others might be, and that's okay and >> needs to be factored in. For better or worse, java.time made a choice >> to be unforgiving in regard to overflow and is very upfront about it. >> It's not only proposed Duration.MAX. The same thing happens if you try >> this >> >> Instant.MAX.toEpochMilli() >> >> I guess my point is that doing calendar arithmetic on an unknown value >> is probably wrong. Doing it on a known huge/edge-case value is surely >> wrong. So back to your data. I would be interested to see what >> triggers overflows for your Durations.MAX. >> >> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever wrote: >> > >> > Hi all, >> > >> > Internally at Google, we've had a Durations.MAX constant exposed for the past 7 years. It now has about 700 usages across our depot, which I can try to categorize (at a future date). >> > >> > While I haven't performed that analysis yet, I think exposing this constant was a bit of a mistake. People seem to want to use MAX to mean "forever" (often in regards to an RPC deadline). This works fine as long as every single layer that touches the deadline is very careful about overflow. The only reasonable thing you can do with MAX is compareTo() and equals(). Attempting to do any simple math operation (e.g., now+deadline) is going to explode. Additionally, decomposing Duration.MAX explodes for any sub-second precision (e.g., toMillis()). >> > >> > As we dug into this, another proposal came up which was something like Durations.VERY_LONG. This duration would be longer than any reasonable finite duration but not long enough to cause an overflow when added to any reasonable time. E.g., a million years would probably satisfy both criteria. This would mean math operations and decompositions won't explode (well, microseconds and nanoseconds still would), and it could safely be used as a relative timeout. >> > >> > As I mentioned above, I'd be happy to try to categorize a sample of our 700 existing usages if folks think that would be useful for this proposal. >> > >> > Thanks, >> > >> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem team) >> > >> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo wrote: >> >> >> >> If I understood you correctly, you think we should also add >> >> Duration.MIN. If so, what use case do you envision for it? Or we add >> >> if purely for symmetry with Instant? >> >> >> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo wrote: >> >> > >> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne wrote: >> >> > > >> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! >> >> > > The constants would be MAX/MIN as per classes like Instant. >> >> > > Stephen >> >> > >> >> > I thought that naming could be tricky :) The public constant >> >> > Duration.ZERO and the public method isZero() are already there. >> >> > However, it does not preclude us from naming a new constant MAX. >> > >> > >> > >> > -- >> > kak >> > > > -- > kak > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cstein at openjdk.org Thu Sep 4 22:01:57 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 4 Sep 2025 22:01:57 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: References: Message-ID: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Update to use correct library directories See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files - 8361950: Set required version to 8+2 - 8361950: Update to use jtreg 8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26261/files - new: https://git.openjdk.org/jdk/pull/26261/files/56006240..12b0d0f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=02-03 Stats: 20940 lines in 1016 files changed: 14715 ins; 2669 del; 3556 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From emcmanus at google.com Thu Sep 4 22:02:19 2025 From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=) Date: Thu, 4 Sep 2025 15:02:19 -0700 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: Two typical use cases: // 1. Sentinel Duration min = Duration.MAX; for (var foo : something()) { if (foo.duration().compareTo(min) < 0) { min = foo.duration(); } } // 2. "Forever" void frob(Optional optionalTimeout) { Duration timeout = optionalTimeout.orElse(Duration.MAX); Instant start = Instant.now(); boolean done = false; while (!done && startTime.until(Instant.now()).compareTo(timeout) < 0) {...} } The second case illustrates why this is potentially a bit delicate. You better not write this: void frob(Optional optionalTimeout) { Duration timeout = optionalTimeout.orElse(Duration.MAX); Instant deadline = Instant.now().plus(timeout); // oops boolean done = false; while (!done && Instant.now().isBefore(deadline)) {...} } Like Kevin, I am skeptical about Duration.MIN. If it means the most negative Duration, that is just Duration.MAX.negated(); and if it means the smallest positive Duration, that is just Duration.ofNanos(1). On Wed, 3 Sept 2025 at 18:32, Roger Riggs wrote: > Hi, > > I'd be interested in the range of use cases for Duration.MAX or MIN. > > But for deadlines, I think the code should compute the deadline from a > Duration of its choice based on the use. > Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores > information about the particular use that is relevant. Its just sloppy code > that doesn't bother to express how long is long enough to meet operational > parameters. > > YMMV, Roger > > On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: > > Duration.MIN is a whole 'nother bag of worms, because Durations are signed > (they can be positive or negative...or zero). Internally we also have > Durations.MIN, but it's not public ... and along with it, I left myself a > helpful note about naming: > > /** The minimum supported {@code Duration}, approximately -292 billion > years. */ > // Note: before making this constant public, consider that "MIN" might > not be a great name (not > // everyone knows that Durations can be negative!). > static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); > > This reminds me of Double.MIN_VALUE (which is the smallest _positive_ > double value) --- we've seen Double.MIN_VALUE misused so much that we > introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large > percent of Double.MIN_VALUE users actually want the smallest possible > negative value, aka -Double.MAX_VALUE. > > If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), > but rather Duration.ofSeconds(Long.MIN_VALUE). > > On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: > >> If you ask me, I don?t find it very useful, It won?t work for >> arithmetrics, even the APIs would have a hard time using it (how do you >> express the deadline) and APIs with a timeout parameter do have a good >> reason for it, better pick ?possible? values for better self healing and >> unstuck of systems. In fact I would err on the smaller side in combination >> with expecting spurious wakeups. >> >> BTW, when you introduce MIN as well, maybe also think about min >> precision, min delta or such. Will it always be 1 nano? >> >> Gru?, >> Bernd >> -- >> https://bernd.eckenfels.net >> ------------------------------ >> *Von:* core-libs-dev im Auftrag von >> Pavel Rappo >> *Gesendet:* Donnerstag, September 4, 2025 12:41 AM >> *An:* Kurt Alfred Kluever >> *Cc:* Stephen Colebourne ; core-libs-dev < >> core-libs-dev at openjdk.org> >> *Betreff:* Re: Duration.MAX_VALUE >> >> This is useful; thanks. It would be good to see more of your data. >> >> My use case is also duration which practically means **forever**. I >> pass it to methods that accept timeouts, and expect these methods to >> correctly interpret it. >> >> One example of a practical interpretation is >> java.util.concurrent.TimeUnit.convert(Duration). This method never >> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is >> roughly 292 years. >> >> Would I be okay, if the proposed duration didn't reflect **forever** >> but instead reflected **long enough**? I think so. But it still >> somehow feels wrong to make it less than maximum representable value. >> >> Personally, I'm not interested in calendar arithmetic, that is, in >> adding or subtracting durations. Others might be, and that's okay and >> needs to be factored in. For better or worse, java.time made a choice >> to be unforgiving in regard to overflow and is very upfront about it. >> It's not only proposed Duration.MAX. The same thing happens if you try >> this >> >> Instant.MAX.toEpochMilli() >> >> I guess my point is that doing calendar arithmetic on an unknown value >> is probably wrong. Doing it on a known huge/edge-case value is surely >> wrong. So back to your data. I would be interested to see what >> triggers overflows for your Durations.MAX. >> >> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever >> wrote: >> > >> > Hi all, >> > >> > Internally at Google, we've had a Durations.MAX constant exposed for >> the past 7 years. It now has about 700 usages across our depot, which I can >> try to categorize (at a future date). >> > >> > While I haven't performed that analysis yet, I think exposing this >> constant was a bit of a mistake. People seem to want to use MAX to mean >> "forever" (often in regards to an RPC deadline). This works fine as long as >> every single layer that touches the deadline is very careful about >> overflow. The only reasonable thing you can do with MAX is compareTo() and >> equals(). Attempting to do any simple math operation (e.g., now+deadline) >> is going to explode. Additionally, decomposing Duration.MAX explodes for >> any sub-second precision (e.g., toMillis()). >> > >> > As we dug into this, another proposal came up which was something like >> Durations.VERY_LONG. This duration would be longer than any reasonable >> finite duration but not long enough to cause an overflow when added to any >> reasonable time. E.g., a million years would probably satisfy both >> criteria. This would mean math operations and decompositions won't explode >> (well, microseconds and nanoseconds still would), and it could safely be >> used as a relative timeout. >> > >> > As I mentioned above, I'd be happy to try to categorize a sample of our >> 700 existing usages if folks think that would be useful for this proposal. >> > >> > Thanks, >> > >> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem >> team) >> > >> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo >> wrote: >> >> >> >> If I understood you correctly, you think we should also add >> >> Duration.MIN. If so, what use case do you envision for it? Or we add >> >> if purely for symmetry with Instant? >> >> >> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo >> wrote: >> >> > >> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne < >> scolebourne at joda.org> wrote: >> >> > > >> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! >> >> > > The constants would be MAX/MIN as per classes like Instant. >> >> > > Stephen >> >> > >> >> > I thought that naming could be tricky :) The public constant >> >> > Duration.ZERO and the public method isZero() are already there. >> >> > However, it does not preclude us from naming a new constant MAX. >> > >> > >> > >> > -- >> > kak >> >> > > -- > kak > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5281 bytes Desc: S/MIME Cryptographic Signature URL: From rriggs at openjdk.org Thu Sep 4 22:15:07 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 22:15:07 GMT Subject: RFR: 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 17:06:32 GMT, Naoto Sato wrote: >> Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further requireNonNull() LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27060#pullrequestreview-3187358527 From bpb at openjdk.org Thu Sep 4 22:15:11 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 4 Sep 2025 22:15:11 GMT Subject: Integrated: 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications In-Reply-To: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> References: <65drHtakwhBTI30jngtpjsHeNR0zfKmfI7_9E7XABb0=.71ea0058-6120-418c-9bef-d867be777510@github.com> Message-ID: <1QQa1cV3DNTCTSSDWVCUJL2-llwOsVh7wPfiMuhL1hE=.f6b418e8-ad18-4890-92cc-a88fbc26fbb6@github.com> On Fri, 29 Aug 2025 15:01:51 GMT, Brian Burkhalter wrote: > Attempt to improve the verbiage of the `java.io.File` specification to make it clearer whether a given method operates only on an abstract pathname or on the actual file system entry it denotes. This pull request has now been integrated. Changeset: 58107071 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/581070715ab1ef081032b78ceb3c2cfbdbcff611 Stats: 101 lines in 1 file changed: 13 ins; 2 del; 86 mod 8366102: Clarification Needed: Symbolic Link Handling in File API Specifications Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/27006 From rriggs at openjdk.org Thu Sep 4 22:17:49 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 22:17:49 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v7] In-Reply-To: References: Message-ID: <55whpk9J8u7yaUeostjLZnA0Bc9q1Yu73uGok5KvFuI=.d8b4932c-274a-4e8c-be93-2e5986d9cf4d@github.com> > The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. > > The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. > > The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into 8364361-process-autocloseable - Expand the description of close() to describe the behavior of destroying the process. - javadoc tweaks - Misc, javadoc cleanup Simplified the Interrupt handling in ProcessCloseTest.ProcessCommand.ExpectExit. - Revisited handling of IOExceptions to throw instead of completely ignoring or logging. - Merge branch 'master' into 8364361-process-autocloseable - Throw IOExceptions on close instead of logging. - The close method is idempotent, it will only close the streams and destroy the process on the first call to close. - Updates from review comments: - Editorial improvements to javadoc - Exceptions that occur closing streams are quietly logged to the java.lang.Process system log as DEBUG - The prototype code attempting to wait for process exit is removed, it provided marginal benefit and raised complexity due to interrupt handling - Test updates for racy test cases that are not errors - 8364361: [process] java.lang.Process should implement close and be AutoCloseable Specify and implement AutoCloseable for Process. Add tests and example code as a snippet. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26649/files - new: https://git.openjdk.org/jdk/pull/26649/files/d0c74cb7..174fc1d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=05-06 Stats: 29052 lines in 1280 files changed: 18702 ins; 5822 del; 4528 mod Patch: https://git.openjdk.org/jdk/pull/26649.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649 PR: https://git.openjdk.org/jdk/pull/26649 From rriggs at openjdk.org Thu Sep 4 22:17:50 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 4 Sep 2025 22:17:50 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v6] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 12:28:15 GMT, David Lloyd wrote: >> `DestroyForcibly` is an escalation that should only be used with a known poorly behaved process; and that's up to the programmer. It is the equivalent of `kill -9`. >> It should not be used in the normal case. Unfortunately, Windows does not have a polite, please terminate API so `destroy` has the same behavior as `destroyForcibly`. >> If the caller uses `process.waitFor()` within the try-catch, the process will have terminated, possibly based on the stream closings, and `destroy()` will not be called. >> If emphasis is needed, the javadoc can elaborate. > >> `DestroyForcibly` is an escalation that should only be used with a known poorly behaved process; and that's up to the programmer. It is the equivalent of `kill -9`. It should not be used in the normal case. Unfortunately, Windows does not have a polite, please terminate API so `destroy` has the same behavior as `destroyForcibly`. > > This is my point exactly; the behavior will differ between Windows and non-Windows. (I didn't want to name-and-shame any particular OS though.) :-) > >> If the caller uses `process.waitFor()` within the try-catch, the process will have terminated, possibly based on the stream closings, and `destroy()` will not be called. If emphasis is needed, the javadoc can elaborate. > > OK. Clarifying in the javadoc would be option three then (the other two options being the two ways mentioned to make the behavior equitable between platforms). Added a description of how destroy behaves, normal termination, and a suggestion to call `waitFor` to allow for clean up and normal exit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2323627946 From kevin.bourrillion at oracle.com Thu Sep 4 22:22:14 2025 From: kevin.bourrillion at oracle.com (Kevin Bourrillion) Date: Thu, 4 Sep 2025 22:22:14 +0000 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: Of course, the problem with this code is that if `something()` is ever unexpectedly empty, suddenly that `MAX` value is going to get actually used for something, and who knows what might happen. It?s, of course, vulnerable to the ?let?s just add a little? problem, same as the other case. It would seem safer to address the empty case explicitly? but then you don?t need `MAX` anymore, you can just initialize `min` to the first value. This way you?d have a variable that was never bogus at any time. Of course, I am not suggesting that the potential for misuse is a sufficient argument for not offering something. Only that I?m not sure this use case is motivating for offering it. From: core-libs-dev on behalf of ?amonn McManus Date: Thursday, September 4, 2025 at 3:03?PM To: Roger Riggs Cc: core-libs-dev at openjdk.org Subject: Re: Duration.MAX_VALUE Two typical use cases: // 1. Sentinel Duration min = Duration.MAX; for (var foo : something()) { if (foo.duration().compareTo(min) < 0) { min = foo.duration(); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Thu Sep 4 22:30:14 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 4 Sep 2025 17:30:14 -0500 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: Just for the record, I think the most "correct" thing to do is fully use Optional instead and avoid any need for MAX. And by "correct" I mean "probably more tedious and annoying" :) // 1. Sentinel Optional min = somethingStream() .reduce(BinaryOperator.minBy(Something::compareTo)); // 2. "Forever" void frob(Optional optionalTimeout) { Instant stop = optionalTimeout.map(Instant.now()::plus); boolean done = false; while (!done && stop.map(s -> s.compareTo(Instant.now()) <= 0).orElse(false)) {...} } -Archie On Thu, Sep 4, 2025 at 5:03?PM ?amonn McManus wrote: > Two typical use cases: > > // 1. Sentinel > Duration min = Duration.MAX; > for (var foo : something()) { > if (foo.duration().compareTo(min) < 0) { > min = foo.duration(); > } > } > > // 2. "Forever" > void frob(Optional optionalTimeout) { > Duration timeout = optionalTimeout.orElse(Duration.MAX); > Instant start = Instant.now(); > boolean done = false; > while (!done && startTime.until(Instant.now()).compareTo(timeout) < 0) > {...} > } > > The second case illustrates why this is potentially a bit delicate. You > better not write this: > > void frob(Optional optionalTimeout) { > Duration timeout = optionalTimeout.orElse(Duration.MAX); > Instant deadline = Instant.now().plus(timeout); // oops > boolean done = false; > while (!done && Instant.now().isBefore(deadline)) {...} > } > > Like Kevin, I am skeptical about Duration.MIN. If it means the most > negative Duration, that is just Duration.MAX.negated(); and if it means the > smallest positive Duration, that is just Duration.ofNanos(1). > > On Wed, 3 Sept 2025 at 18:32, Roger Riggs wrote: > >> Hi, >> >> I'd be interested in the range of use cases for Duration.MAX or MIN. >> >> But for deadlines, I think the code should compute the deadline from a >> Duration of its choice based on the use. >> Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores >> information about the particular use that is relevant. Its just sloppy code >> that doesn't bother to express how long is long enough to meet operational >> parameters. >> >> YMMV, Roger >> >> On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: >> >> Duration.MIN is a whole 'nother bag of worms, because Durations are >> signed (they can be positive or negative...or zero). Internally we also >> have Durations.MIN, but it's not public ... and along with it, I left >> myself a helpful note about naming: >> >> /** The minimum supported {@code Duration}, approximately -292 billion >> years. */ >> // Note: before making this constant public, consider that "MIN" might >> not be a great name (not >> // everyone knows that Durations can be negative!). >> static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); >> >> This reminds me of Double.MIN_VALUE (which is the smallest _positive_ >> double value) --- we've seen Double.MIN_VALUE misused so much that we >> introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large >> percent of Double.MIN_VALUE users actually want the smallest possible >> negative value, aka -Double.MAX_VALUE. >> >> If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), >> but rather Duration.ofSeconds(Long.MIN_VALUE). >> >> On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: >> >>> If you ask me, I don?t find it very useful, It won?t work for >>> arithmetrics, even the APIs would have a hard time using it (how do you >>> express the deadline) and APIs with a timeout parameter do have a good >>> reason for it, better pick ?possible? values for better self healing and >>> unstuck of systems. In fact I would err on the smaller side in combination >>> with expecting spurious wakeups. >>> >>> BTW, when you introduce MIN as well, maybe also think about min >>> precision, min delta or such. Will it always be 1 nano? >>> >>> Gru?, >>> Bernd >>> -- >>> https://bernd.eckenfels.net >>> ------------------------------ >>> *Von:* core-libs-dev im Auftrag von >>> Pavel Rappo >>> *Gesendet:* Donnerstag, September 4, 2025 12:41 AM >>> *An:* Kurt Alfred Kluever >>> *Cc:* Stephen Colebourne ; core-libs-dev < >>> core-libs-dev at openjdk.org> >>> *Betreff:* Re: Duration.MAX_VALUE >>> >>> This is useful; thanks. It would be good to see more of your data. >>> >>> My use case is also duration which practically means **forever**. I >>> pass it to methods that accept timeouts, and expect these methods to >>> correctly interpret it. >>> >>> One example of a practical interpretation is >>> java.util.concurrent.TimeUnit.convert(Duration). This method never >>> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is >>> roughly 292 years. >>> >>> Would I be okay, if the proposed duration didn't reflect **forever** >>> but instead reflected **long enough**? I think so. But it still >>> somehow feels wrong to make it less than maximum representable value. >>> >>> Personally, I'm not interested in calendar arithmetic, that is, in >>> adding or subtracting durations. Others might be, and that's okay and >>> needs to be factored in. For better or worse, java.time made a choice >>> to be unforgiving in regard to overflow and is very upfront about it. >>> It's not only proposed Duration.MAX. The same thing happens if you try >>> this >>> >>> Instant.MAX.toEpochMilli() >>> >>> I guess my point is that doing calendar arithmetic on an unknown value >>> is probably wrong. Doing it on a known huge/edge-case value is surely >>> wrong. So back to your data. I would be interested to see what >>> triggers overflows for your Durations.MAX. >>> >>> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever >>> wrote: >>> > >>> > Hi all, >>> > >>> > Internally at Google, we've had a Durations.MAX constant exposed for >>> the past 7 years. It now has about 700 usages across our depot, which I can >>> try to categorize (at a future date). >>> > >>> > While I haven't performed that analysis yet, I think exposing this >>> constant was a bit of a mistake. People seem to want to use MAX to mean >>> "forever" (often in regards to an RPC deadline). This works fine as long as >>> every single layer that touches the deadline is very careful about >>> overflow. The only reasonable thing you can do with MAX is compareTo() and >>> equals(). Attempting to do any simple math operation (e.g., now+deadline) >>> is going to explode. Additionally, decomposing Duration.MAX explodes for >>> any sub-second precision (e.g., toMillis()). >>> > >>> > As we dug into this, another proposal came up which was something like >>> Durations.VERY_LONG. This duration would be longer than any reasonable >>> finite duration but not long enough to cause an overflow when added to any >>> reasonable time. E.g., a million years would probably satisfy both >>> criteria. This would mean math operations and decompositions won't explode >>> (well, microseconds and nanoseconds still would), and it could safely be >>> used as a relative timeout. >>> > >>> > As I mentioned above, I'd be happy to try to categorize a sample of >>> our 700 existing usages if folks think that would be useful for this >>> proposal. >>> > >>> > Thanks, >>> > >>> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem >>> team) >>> > >>> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo >>> wrote: >>> >> >>> >> If I understood you correctly, you think we should also add >>> >> Duration.MIN. If so, what use case do you envision for it? Or we add >>> >> if purely for symmetry with Instant? >>> >> >>> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo >>> wrote: >>> >> > >>> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne < >>> scolebourne at joda.org> wrote: >>> >> > > >>> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! >>> >> > > The constants would be MAX/MIN as per classes like Instant. >>> >> > > Stephen >>> >> > >>> >> > I thought that naming could be tricky :) The public constant >>> >> > Duration.ZERO and the public method isZero() are already there. >>> >> > However, it does not preclude us from naming a new constant MAX. >>> > >>> > >>> > >>> > -- >>> > kak >>> >>> >> >> -- >> kak >> >> >> -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at gmail.com Thu Sep 4 22:50:04 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Thu, 4 Sep 2025 23:50:04 +0100 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: I've just started with calendar arithmetic, but I can already see how tricky it is. Here are a few examples: 1. Existence of negative durations, which others mentioned in this thread. 2. There's the following asymmetry: while maximum duration is Duration.ofSecond(Long.MAX_VALUE, 999_999_999), minimum duration is Duration.ofSecond(Long.MIN_VALUE, 0). 3. There's also the fact that duration between any two instants is two orders of magnitude smaller than maximum duration. That is, var MAX = Duration.ofSeconds(Long.MAX_VALUE, 999_999_999); var MAX_BETWEEN = Duration.between(Instant.MIN, Instant.MAX); System.out.println(MAX.compareTo(MAX_BETWEEN)); System.out.println(MAX.dividedBy(MAX_BETWEEN)); outputs 1 146 (Kudos to Daniel Fuchs for this example.) I get that people want to calculate deadlines. Given that the API is hostile to overflows, calculating deadline from arbitrary values is not right. Clients who want to robustly calculate a deadline given an initial timestamp and a timeout should bite the bullet and use something similar to this: static Instant add(Instant i, Duration d) { if (d.isNegative()) { return Duration.between(i, Instant.MIN).compareTo(d) >= 0 ? Instant.MIN : i.plus(d); } else { return Duration.between(i, Instant.MAX).compareTo(d) <= 0 ? Instant.MAX : i.plus(d); } } (I won't be surprised if that snippet has bugs.) On Thu, Sep 4, 2025 at 10:33?PM Stephen Colebourne wrote: > > The best reason for adding MAX (max positive) and MIN (max negative) > is that the alternative is digging around in the Javadoc to figure it > out, and probably getting it wrong. It also provides a great place to > document the usage issues, which are no different to Long.MAX_VALUE or > Instant.MAX. Which is the bigger point here - MAX/MIN values are > *always* weird, and I really wouldn't overthink this. > > I understand the appeal of a BIG value, but it is a domain specific > thing and not for the JDK in my view. > > Stephen > > > On Thu, 4 Sept 2025 at 02:33, Roger Riggs wrote: > > > > Hi, > > > > I'd be interested in the range of use cases for Duration.MAX or MIN. > > > > But for deadlines, I think the code should compute the deadline from a Duration of its choice based on the use. > > Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores information about the particular use that is relevant. Its just sloppy code that doesn't bother to express how long is long enough to meet operational parameters. > > > > YMMV, Roger > > > > On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: > > > > Duration.MIN is a whole 'nother bag of worms, because Durations are signed (they can be positive or negative...or zero). Internally we also have Durations.MIN, but it's not public ... and along with it, I left myself a helpful note about naming: > > > > /** The minimum supported {@code Duration}, approximately -292 billion years. */ > > // Note: before making this constant public, consider that "MIN" might not be a great name (not > > // everyone knows that Durations can be negative!). > > static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); > > > > This reminds me of Double.MIN_VALUE (which is the smallest _positive_ double value) --- we've seen Double.MIN_VALUE misused so much that we introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large percent of Double.MIN_VALUE users actually want the smallest possible negative value, aka -Double.MAX_VALUE. > > > > If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), but rather Duration.ofSeconds(Long.MIN_VALUE). > > > > On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: > >> > >> If you ask me, I don?t find it very useful, It won?t work for arithmetrics, even the APIs would have a hard time using it (how do you express the deadline) and APIs with a timeout parameter do have a good reason for it, better pick ?possible? values for better self healing and unstuck of systems. In fact I would err on the smaller side in combination with expecting spurious wakeups. > >> > >> BTW, when you introduce MIN as well, maybe also think about min precision, min delta or such. Will it always be 1 nano? > >> > >> Gru?, > >> Bernd > >> -- > >> https://bernd.eckenfels.net > >> ________________________________ > >> Von: core-libs-dev im Auftrag von Pavel Rappo > >> Gesendet: Donnerstag, September 4, 2025 12:41 AM > >> An: Kurt Alfred Kluever > >> Cc: Stephen Colebourne ; core-libs-dev > >> Betreff: Re: Duration.MAX_VALUE > >> > >> This is useful; thanks. It would be good to see more of your data. > >> > >> My use case is also duration which practically means **forever**. I > >> pass it to methods that accept timeouts, and expect these methods to > >> correctly interpret it. > >> > >> One example of a practical interpretation is > >> java.util.concurrent.TimeUnit.convert(Duration). This method never > >> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is > >> roughly 292 years. > >> > >> Would I be okay, if the proposed duration didn't reflect **forever** > >> but instead reflected **long enough**? I think so. But it still > >> somehow feels wrong to make it less than maximum representable value. > >> > >> Personally, I'm not interested in calendar arithmetic, that is, in > >> adding or subtracting durations. Others might be, and that's okay and > >> needs to be factored in. For better or worse, java.time made a choice > >> to be unforgiving in regard to overflow and is very upfront about it. > >> It's not only proposed Duration.MAX. The same thing happens if you try > >> this > >> > >> Instant.MAX.toEpochMilli() > >> > >> I guess my point is that doing calendar arithmetic on an unknown value > >> is probably wrong. Doing it on a known huge/edge-case value is surely > >> wrong. So back to your data. I would be interested to see what > >> triggers overflows for your Durations.MAX. > >> > >> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever wrote: > >> > > >> > Hi all, > >> > > >> > Internally at Google, we've had a Durations.MAX constant exposed for the past 7 years. It now has about 700 usages across our depot, which I can try to categorize (at a future date). > >> > > >> > While I haven't performed that analysis yet, I think exposing this constant was a bit of a mistake. People seem to want to use MAX to mean "forever" (often in regards to an RPC deadline). This works fine as long as every single layer that touches the deadline is very careful about overflow. The only reasonable thing you can do with MAX is compareTo() and equals(). Attempting to do any simple math operation (e.g., now+deadline) is going to explode. Additionally, decomposing Duration.MAX explodes for any sub-second precision (e.g., toMillis()). > >> > > >> > As we dug into this, another proposal came up which was something like Durations.VERY_LONG. This duration would be longer than any reasonable finite duration but not long enough to cause an overflow when added to any reasonable time. E.g., a million years would probably satisfy both criteria. This would mean math operations and decompositions won't explode (well, microseconds and nanoseconds still would), and it could safely be used as a relative timeout. > >> > > >> > As I mentioned above, I'd be happy to try to categorize a sample of our 700 existing usages if folks think that would be useful for this proposal. > >> > > >> > Thanks, > >> > > >> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem team) > >> > > >> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo wrote: > >> >> > >> >> If I understood you correctly, you think we should also add > >> >> Duration.MIN. If so, what use case do you envision for it? Or we add > >> >> if purely for symmetry with Instant? > >> >> > >> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo wrote: > >> >> > > >> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne wrote: > >> >> > > > >> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! > >> >> > > The constants would be MAX/MIN as per classes like Instant. > >> >> > > Stephen > >> >> > > >> >> > I thought that naming could be tricky :) The public constant > >> >> > Duration.ZERO and the public method isZero() are already there. > >> >> > However, it does not preclude us from naming a new constant MAX. > >> > > >> > > >> > > >> > -- > >> > kak > >> > > > > > > -- > > kak > > > > From liach at openjdk.org Thu Sep 4 23:22:40 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 23:22:40 GMT Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed [v2] In-Reply-To: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> References: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> Message-ID: On Thu, 4 Sep 2025 18:24:57 GMT, Matias Saavedra Silva wrote: >> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright Looks reasonable, and ClassFile API changes look good. In JVMS 24 [4.10.1.9.invokespecial](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.10.1.9.invokespecial): > In the special case of initializing the current object (that is, when invoking for type uninitializedThis), the original frame typically holds an uninitialized object in local variable 0 and has flag flagThisUninit. Normal termination of invokespecial initializes the uninitialized object and turns off the flagThisUninit flag. But if the invokespecial invocation throws an exception, the exception frame contains the broken object (with type top) and the flagThisUninit flag (the old flag). There is no way to perform a return instruction given that type state, so the handler would have to throw another exception (or loop forever). In fact, it's not even possible to express a handler with that type state, because there is no way for a stack frame, as expressed by the StackMapTable attribute ([?4.7.4](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.7.4)), to carry flagThisUninit without any accompanying use of type uninitializedThis. Justifies this change. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27107#pullrequestreview-3187515624 From smarks at openjdk.org Thu Sep 4 23:49:27 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 4 Sep 2025 23:49:27 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 16:29:32 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refining comments src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 133: > 131: Charset.forName(StaticProperty.stdinEncoding(), UTF_8.INSTANCE), > 132: Charset.forName(StaticProperty.stdoutEncoding(), UTF_8.INSTANCE))) : > 133: Optional.empty(); (Finally getting back to this.) The code returns an Optional containing a JdkConsoleImpl instance, or an empty Optional. However the comment above says it returns a JdkConsoleImpl instance or null. Which do we want it to be? Either is OK, but the comment should agree with the code. I think @wangweij might want to weigh in here since his code will be calling this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2323743307 From naoto at openjdk.org Thu Sep 4 23:49:28 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 4 Sep 2025 23:49:28 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: References: Message-ID: <0ub8yevcVcLcmGSHH4edEdSjfrUwW5rAw140-Q4VuUM=.82ba246e-eae9-4b1b-a2d1-f43e8530da1b@github.com> On Thu, 4 Sep 2025 23:28:22 GMT, Stuart Marks wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Refining comments > > src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 133: > >> 131: Charset.forName(StaticProperty.stdinEncoding(), UTF_8.INSTANCE), >> 132: Charset.forName(StaticProperty.stdoutEncoding(), UTF_8.INSTANCE))) : >> 133: Optional.empty(); > > (Finally getting back to this.) > > The code returns an Optional containing a JdkConsoleImpl instance, or an empty Optional. However the comment above says it returns a JdkConsoleImpl instance or null. Which do we want it to be? Either is OK, but the comment should agree with the code. > > I think @wangweij might want to weigh in here since his code will be calling this. Ah, yes. Comment does not align with the code. I am fine either way too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2323752183 From liach at openjdk.org Fri Sep 5 00:00:34 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 00:00:34 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v4] In-Reply-To: References: Message-ID: > java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. > > Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". > > However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. > > To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Jorn review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27010/files - new: https://git.openjdk.org/jdk/pull/27010/files/fa581ff3..c08ed390 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27010&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27010&range=02-03 Stats: 31 lines in 5 files changed: 0 ins; 24 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27010.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27010/head:pull/27010 PR: https://git.openjdk.org/jdk/pull/27010 From liach at openjdk.org Fri Sep 5 00:01:13 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 00:01:13 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 17:56:07 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> More ioi review > > src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java line 46: > >> 44: /// arguments for currying. >> 45: /// >> 46: /// Each BMH acts like a strongly-typed argument list, where the types are > > What do you mean with 'strongly-typed argument list'? Bound method handles are not just used for arguments. > > I'd described BMH as method handles with a number of extra fields that can be referenced from its lambda form. Yep, I reworded to: > Each BMH class supports a number of values, each of a particular [BasicType]. > This per-class value type and count information is recorded by [SpeciesData]. > A [Specializer] manages lookup for any species. > src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 58: > >> 56: /// >> 57: /// Since lambda forms and bound method handle species are closely tied to >> 58: /// method types, which have many varieties, this generator needs *traces* to > > Since this is the first mention of 'traces' in this file, I think it would be great if you could explain what they are, how they are generated (with the system properties), and what their format are (probably just a link to the right methods where the printing happens). The link is right below to `generateHolderClasses` - it describes the process without mandating the contents, and links to MethodHandleStatics#traceLambdaForm and MethodHandleStatics#traceSpeciesType. I think that is sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2323764132 PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2323763191 From liach at openjdk.org Fri Sep 5 00:01:38 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 00:01:38 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 17:57:46 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 205: >> >>> 203: /// >>> 204: /// The method names of this class are internal tokens recognized by >>> 205: /// [InvokerBytecodeGenerator#lookupPregenerated] and is subject to change. >> >> Suggestion: >> >> /// [InvokerBytecodeGenerator#lookupPregenerated] and are subject to change. > > Same elsewhere Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27010#discussion_r2323763648 From dlong at openjdk.org Fri Sep 5 00:28:20 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 5 Sep 2025 00:28:20 GMT Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed [v2] In-Reply-To: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> References: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> Message-ID: On Thu, 4 Sep 2025 18:24:57 GMT, Matias Saavedra Silva wrote: >> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27107#pullrequestreview-3187604303 From jlu at openjdk.org Fri Sep 5 00:59:34 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 00:59:34 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests Message-ID: This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). **DFSDeserialization142.java & DFSSerialization142.java** (D) - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. **NumberFormat/DFSSerialization.java** (D) - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. **SerializationLoad.java & SerializationSave.java** (D) - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. **NumberRegression.java** (M) - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/27108/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366733 Stats: 1051 lines in 13 files changed: 214 ins; 787 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/27108.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27108/head:pull/27108 PR: https://git.openjdk.org/jdk/pull/27108 From jvernee at openjdk.org Fri Sep 5 01:51:14 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Sep 2025 01:51:14 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v4] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 00:00:34 GMT, Chen Liang wrote: >> java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. >> >> Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". >> >> However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. >> >> To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Jorn review Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27010#pullrequestreview-3187769410 From iklam at openjdk.org Fri Sep 5 02:38:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Sep 2025 02:38:10 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v4] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 00:00:34 GMT, Chen Liang wrote: >> java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. >> >> Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". >> >> However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. >> >> To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Jorn review Looks good! ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27010#pullrequestreview-3187824234 From darcy at openjdk.org Fri Sep 5 03:40:17 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 5 Sep 2025 03:40:17 GMT Subject: RFR: 8077587: BigInteger Roots [v81] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 08:45:33 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Small optimization and format comments src/java.base/share/classes/java/math/MutableBigInteger.java line 174: > 172: // to the formulae in JLS, Section 20.10.22. > 173: long valBits = Double.doubleToRawLongBits(val); > 174: int exponent = (int) ((valBits >> 52) & 0x7ffL) - 1075; Hmm. I'd prefer to see Math.getExponent() used here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2324018755 From darcy at openjdk.org Fri Sep 5 03:45:22 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 5 Sep 2025 03:45:22 GMT Subject: RFR: 8077587: BigInteger Roots [v81] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 08:45:33 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Small optimization and format comments src/java.base/share/classes/java/math/MutableBigInteger.java line 175: > 173: long valBits = Double.doubleToRawLongBits(val); > 174: int exponent = (int) ((valBits >> 52) & 0x7ffL) - 1075; > 175: long significand = (valBits & ((1L << 52) - 1)) | (1L << 52); I think that would be better with an explanatory comment -- "OR in implicit bit..." (There are constants for the significand defined in a package-private class in java.lang so no directly usable from here.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24898#discussion_r2324022628 From vyazici at openjdk.org Fri Sep 5 06:43:21 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 5 Sep 2025 06:43:21 GMT Subject: Integrated: 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:36:20 GMT, Volkan Yazici wrote: > [JDK-8356439] (#26413) conflicted with [JDK-8362893] (#26493), caused `tier1` failures, and hence, backed out in [JDK-8366693] (#27050). This PR reintroduces JDK-8356439 with sufficient fixes. > > [JDK-8356439]: https://bugs.openjdk.org/browse/JDK-8356439 > [JDK-8362893]: https://bugs.openjdk.org/browse/JDK-8362893 > [JDK-8366693]: https://bugs.openjdk.org/browse/JDK-8366693 This pull request has now been integrated. Changeset: a2f8d3c4 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/a2f8d3c4c25fdadf378313ef52185dceee98773d Stats: 469 lines in 9 files changed: 244 ins; 121 del; 104 mod 8366765: [REDO] Rename JavaLangAccess::*NoRepl methods Reviewed-by: rriggs, liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/27084 From scolebourne at joda.org Fri Sep 5 07:12:46 2025 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 5 Sep 2025 08:12:46 +0100 Subject: StableValue and non-deterministic iteration order Message-ID: Back in March 2023 there was a discussion about the non-deterministic iteration order of Map.of() and friends: https://mail.openjdk.org/pipermail/core-libs-dev/2023-March/102865.html It feels like this discussion should be revisited now that we have StableValue. Map.of() is one of the few ways (along with method references and records) that we have at the moment to ensure a chain of trust through for the JVM so it can constant fold. This should (if people are aware) push more people to use Map.of() and friends. The unspecified iteration order is a problem however. In most use cases I have had where Map.of() was viable, I had to revert it or not use it because of the iteration order. IMO, it is fundamentally surprising that the order I enter the data in source code is not retained. More generally, in my experience it is much better for a large codebase to consistently use LinkedHashMap over HashMap as it means that the output is always consistent. My recent use case was in code generation to store a map of bean properties so that the order matches that seen in source code (something that reflection still doesn't supply). The only way this could be done today would be for me to store both a List for the order and a Map for the data, which is wasteful and error prone. The basic options here are: - developers manually hold both a List and Map (very error prone) - developers write their own Map using record as the implementation tool (hacky) - change Map.of() to have a fixed iteration order (allowed by the spec, and IMO what most devs expect) - add SequencedMap.of() or Map.ofOrdered() to allow devs to choose iteration order In summary, the current Map.of() is a bit of a hand grenade IMO, and something I pretty much banned at my previous company. Which is a problem given its key role in StableValue. Stephen From duke at openjdk.org Fri Sep 5 08:19:35 2025 From: duke at openjdk.org (erifan) Date: Fri, 5 Sep 2025 08:19:35 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable Message-ID: Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. Benchmarks on Nvidia Grace machine with 128-bit SVE: Benchmark Unit Before Score Error After Score Error Uplift microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 Benchmarks on Intel 6444y machine with 512-bit avx3: Benchmark Unit Before Score Error After Score Error Uplift microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 microMaskLaneIsSetLong256_var ops/ms 113838.3822 415.784529 360782.0645 710.076899 3.169247 microMaskLaneIsSetLong512_var ops/ms 57314.02695 190.1762 211690.8492 26.47233 3.693526 microMaskLaneIsSetShort128_var ops/ms 57675.58965 65.940976 211549.9551 276.57545 3.667928 microMaskLaneIsSetShort256_var ops/ms 57628.8642 91.957833 211694.0864 16.559412 3.673403 microMaskLaneIsSetShort512_var ops/ms 57845.35211 160.537421 211358.872 660.777147 3.65386 microMaskLaneIsSetShort64_var ops/ms 113848.8846 222.787418 360294.6295 491.425656 3.164674 ------------- Commit messages: - 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable Changes: https://git.openjdk.org/jdk/pull/27113/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27113&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366588 Stats: 170 lines in 4 files changed: 168 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27113/head:pull/27113 PR: https://git.openjdk.org/jdk/pull/27113 From alanb at openjdk.org Fri Sep 5 08:20:12 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 08:20:12 GMT Subject: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:47:33 GMT, Aleksey Shipilev wrote: > GetStackTraceALotWhenPinned test times out every so often in GHA. > > The last sightings are on macos-aarch64: > > > 2025-09-04T10:41:29.357879Z => 87894 of 100000 > 2025-09-04T10:41:30.365534Z => 88105 of 100000 > Timeout signalled after 300 seconds > 2025-09-04T10:41:31.367068Z => 88298 of 100000 > 2025-09-04T10:41:32.377128Z => 88400 of 100000 > > 2025-09-03T10:08:37.713537Z => 74715 of 100000 > 2025-09-03T10:08:38.717750Z => 74818 of 100000 > Timeout signalled after 300 seconds > 2025-09-03T10:08:39.722960Z => 74922 of 100000 > 2025-09-03T10:08:40.726642Z => 75024 of 100000 > > > Looks like we are nearly there, just need fewer iterations. I think like with [JDK-8344577](https://bugs.openjdk.org/browse/JDK-8344577), we just need to extend the test check for AArch64 macs as well. > > Additional testing: > - [x] MacOS AArch64 server fastdebug, `java/lang/Thread/virtual/stress`, 10x Marked as reviewed by alanb (Reviewer). It looks like GH is using a fleet of Reliant Robins as the runners for macOS arm64. Do you know what value of JTREG_JOBS is used for jtreg --concurrency on these apparently 3-core VMs? If concurrency is >1 then I assume we have more than one stress test running concurrently. (The change are okay of course. Right now, the TL handshake for virtual threads is limited to JVMTI usages but that make change, in which case we can re-visit Thread::getStackTrace and avoid the retry during transitions, and reduce the need for the GetStackTraceALotXXX stress tests). ------------- PR Review: https://git.openjdk.org/jdk/pull/27104#pullrequestreview-3188437905 PR Comment: https://git.openjdk.org/jdk/pull/27104#issuecomment-3257482804 From tschatzl at openjdk.org Fri Sep 5 08:39:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 5 Sep 2025 08:39:11 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3188490620 From geliang at kernel.org Fri Sep 5 08:43:16 2025 From: geliang at kernel.org (Geliang Tang) Date: Fri, 05 Sep 2025 16:43:16 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API Message-ID: Hi OpenJDK maintainers, I hope this message finds you well. The purpose of this letter is to propose the integration of Multipath TCP (MPTCP) support into OpenJDK. We have developed a set of patches to enable this functionality and are eager to submit it for upstream inclusion. We would greatly appreciate your feedback and opinions on this contribution. 1. Introduction Multipath TCP (MPTCP), as standardized in RFC 8684, is a major evolution of the TCP protocol. It enables a transport connection to use multiple network paths simultaneously for redundancy, resilience, and bandwidth aggregation. Since its introduction in Linux kernel v5.6, it has become a key technology for modern networking, particularly on mobile devices with multiple interfaces (e.g., Wi-Fi and cellular). Key benefits include: Bandwidth Aggregation: Combine the bandwidth of multiple network links. Seamless Handover: Maintain connections when switching networks without dropping the session. Improved Resilience: Traffic is automatically rerouted if one path fails. For more details, see the project website: https://mptcp.dev. 2. Technical Background On a supporting system like Linux, an MPTCP socket is created by specifying the IPPROTO_MPTCP protocol in the socket() system call instead of IPPROTO_TCP (or 0): int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP); This creates a socket that looks like a standard TCP socket to the application but uses the MPTCP protocol stack underneath. With the Java API, it is possible to create "stream" sockets, but it is not possible to change the last argument, which blocks apps to ask to use MPTCP. 3. Proposed Java API Changes The goal is to allow Java applications to opt-in to using MPTCP when creating sockets, without breaking existing code. The proposed changes are additive and backward-compatible. The core idea is to add a boolean mptcp parameter through the API layers, from the public Socket class down to the native system call. 4. Implementation Plan The implementation involves changes across four layers of the JDK: JNI Layer (sun.nio.ch.Net): Modify Java_sun_nio_ch_Net_socket0 to accept a new jboolean mptcp parameter. The native implementation will be updated to use this parameter: int protocol = mptcp == JNI_TRUE ? IPPROTO_MPTCP : 0; fd = socket(domain, type, protocol); NIO Layer (sun.nio.ch): Add the mptcp parameter to the Net.socket() and Net.serverSocket() methods. Propagate the parameter down to the JNI call. Socket Implementation Layer (java.net): Add the mptcp parameter to the constructor of NioSocketImpl. Within NioSocketImpl, pass the parameter to the Net.socket() or Net.serverSocket() calls. Public API Layer (java.net.Socket & java.net.ServerSocket): Add new constructors that accept the mptcp parameter. Example: // Proposed new constructor public Socket(String host, int port, boolean stream, boolean mptcp) throws IOException { // ... implementation that passes 'mptcp' to NioSocketImpl } 5. Full Implementation The complete working implementation for this proposal is available for review: https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master We look forward to your valuable feedback and suggestions on this proposal. We can create a new issue for this feature, and submit a proper pull request after if that's OK for you. We didn't do that yet because we noticed that it is recommended to send more explanations to this list first. Best regards, MPTCP Upstream Developers From shade at openjdk.org Fri Sep 5 09:09:10 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 Sep 2025 09:09:10 GMT Subject: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:17:09 GMT, Alan Bateman wrote: > It looks like GH is using a fleet of Reliant Robins as the runners for macOS arm64. Do you know what value of JTREG_JOBS is used for jtreg --concurrency on these apparently 3-core VMs? If concurrency is >1 then I assume we have more than one stress test running concurrently. `configure` step says: Build performance summary: * Build jobs: 3 * Memory limit: 7168 MB `TEST_JOBS`, AFAICS from build files, follows the number of build jobs, so, `3`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27104#issuecomment-3257634181 From alan.bateman at oracle.com Fri Sep 5 09:28:59 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 5 Sep 2025 10:28:59 +0100 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: References: Message-ID: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> On 05/09/2025 09:43, Geliang Tang wrote: > : > > 3. Proposed Java API Changes > > The goal is to allow Java applications to opt-in to using MPTCP when > creating sockets, without breaking existing code. The proposed changes > are additive and backward-compatible. > > The core idea is to add a boolean mptcp parameter through the API > layers, from the public Socket class down to the native system call. (moving the discussion to nio-dev and net-dev). Adding new constructors to legacy Socket/ServerSocket may work for your initial prototype but would be problematic to propose as it would bake non-standard features into the standard API. Also many high performance servers use SocketChannel rather than Socket. One suggestion for a next prototype is to model the enablement of MultiPath TCP as as a JDK-specific socket option (see jdk.net.ExtendingSocketOptions). All of the standard APIs for networking sockets define a setOption method for setting socket options. If modeled as a socket option then enabling can create a new AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place so that the original AF_INET6/SOCK_STREAM/0 socket is closed. Enabling can be made to fail if the socket is already bound. It could copy over existing socket options if needed. Look at the built-in (and no longer used) SDP support for an example that does similar with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a socket option defined in jdk.net.ExtendingSocketOptions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From geliang at kernel.org Fri Sep 5 10:05:15 2025 From: geliang at kernel.org (Geliang Tang) Date: Fri, 05 Sep 2025 18:05:15 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> Message-ID: <7de753a3852e66e42e3087e14e94de9a95b3ed59.camel@kernel.org> Hi Alan, Thanks for your reply. On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote: > ? > On 05/09/2025 09:43, Geliang Tang wrote: > ? > ? > > ? > > : > > > > 3. Proposed Java API Changes > > > > The goal is to allow Java applications to opt-in to using MPTCP > > when > > creating sockets, without breaking existing code. The proposed > > changes > > are additive and backward-compatible. > > > > The core idea is to add a boolean mptcp parameter through the API > > layers, from the public Socket class down to the native system > > call. > > ? > ? > ?(moving the discussion to nio-dev and net-dev). > ? > ?Adding new constructors to legacy Socket/ServerSocket may work for > your initial prototype but would be problematic to propose as it > would bake non-standard features into the standard API. Also many > high performance servers use SocketChannel rather than Socket. > ? > ?One suggestion for a next prototype is to model the enablement of > MultiPath TCP as as a JDK-specific socket option (see > jdk.net.ExtendingSocketOptions). All of the standard APIs for > networking sockets define a setOption method for setting socket I was initially concerned that calling setOption() after Socket() creation to convert TCP to MPTCP was too late. Creating an MPTCP socket must be done during the socket() system call. > options. If modeled as a socket option then enabling can create a new > AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place Until I saw here, it should be feasible if the socket can be created again and dup when calling setOption(). I will try to reimplement MPTCP support using jdk.net.ExtendingSocketOptions soon and give you feedback. Thanks, -Geliang > so that the original AF_INET6/SOCK_STREAM/0 socket is closed. > Enabling can be made to fail if the socket is already bound. It could > copy over existing socket options if needed. Look at the built-in > (and no longer used) SDP support for an example that does similar > with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a > socket option defined in jdk.net.ExtendingSocketOptions. > ? > ?-Alan > ? > ? From shade at openjdk.org Fri Sep 5 10:06:11 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 Sep 2025 10:06:11 GMT Subject: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:47:33 GMT, Aleksey Shipilev wrote: > GetStackTraceALotWhenPinned test times out every so often in GHA. > > The last sightings are on macos-aarch64: > > > 2025-09-04T10:41:29.357879Z => 87894 of 100000 > 2025-09-04T10:41:30.365534Z => 88105 of 100000 > Timeout signalled after 300 seconds > 2025-09-04T10:41:31.367068Z => 88298 of 100000 > 2025-09-04T10:41:32.377128Z => 88400 of 100000 > > 2025-09-03T10:08:37.713537Z => 74715 of 100000 > 2025-09-03T10:08:38.717750Z => 74818 of 100000 > Timeout signalled after 300 seconds > 2025-09-03T10:08:39.722960Z => 74922 of 100000 > 2025-09-03T10:08:40.726642Z => 75024 of 100000 > > > Looks like we are nearly there, just need fewer iterations. I think like with [JDK-8344577](https://bugs.openjdk.org/browse/JDK-8344577), we just need to extend the test check for AArch64 macs as well. > > Additional testing: > - [x] MacOS AArch64 server fastdebug, `java/lang/Thread/virtual/stress`, 10x Seeing these tests failing often now. I think I need a second reviewer to integrate this, to make testing cleaner. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27104#issuecomment-3257794227 From geliang at kernel.org Fri Sep 5 10:11:22 2025 From: geliang at kernel.org (Geliang Tang) Date: Fri, 05 Sep 2025 18:11:22 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> Message-ID: Hi Alan, Thanks for your reply. On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote: > ? > On 05/09/2025 09:43, Geliang Tang wrote: > ? > ? > > ? > > : > > > > 3. Proposed Java API Changes > > > > The goal is to allow Java applications to opt-in to using MPTCP > > when > > creating sockets, without breaking existing code. The proposed > > changes > > are additive and backward-compatible. > > > > The core idea is to add a boolean mptcp parameter through the API > > layers, from the public Socket class down to the native system > > call. > > ? > ? > ?(moving the discussion to nio-dev and net-dev). > ? > ?Adding new constructors to legacy Socket/ServerSocket may work for > your initial prototype but would be problematic to propose as it > would bake non-standard features into the standard API. Also many > high performance servers use SocketChannel rather than Socket. > ? > ?One suggestion for a next prototype is to model the enablement of > MultiPath TCP as as a JDK-specific socket option (see > jdk.net.ExtendingSocketOptions). All of the standard APIs for > networking sockets define a setOption method for setting socket I was initially concerned that calling setOption() after Socket() creation to convert TCP to MPTCP was too late. Creating an MPTCP socket must be done during the socket() system call. > options. If modeled as a socket option then enabling can create a new > AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into place Until I saw here, it should be feasible if the socket can be created again and dup when calling setOption(). I will try to reimplement MPTCP support using jdk.net.ExtendingSocketOptions soon and give you feedback. Thanks, -Geliang > so that the original AF_INET6/SOCK_STREAM/0 socket is closed. > Enabling can be made to fail if the socket is already bound. It could > copy over existing socket options if needed. Look at the built-in > (and no longer used) SDP support for an example that does similar > with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a > socket option defined in jdk.net.ExtendingSocketOptions. > ? > ?-Alan > ? > ? From shade at openjdk.org Fri Sep 5 10:16:12 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 Sep 2025 10:16:12 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:13:28 GMT, erifan wrote: > Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. > > Benchmarks on Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 > microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 > microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 > microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 > microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 > microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 > microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 > microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 > microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 > microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 > > > Benchmarks on Intel 6444y machine with 512-bit avx3: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 > microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 > microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 > microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 > microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 > microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 > microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 > microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 > microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 > microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 > microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 > microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 > microMaskLane... This looks fine to me. I took another look at [JDK-8358749](https://bugs.openjdk.org/browse/JDK-8358749), and I think this is the only place where we can really accept the non-constant input. In all other cases, we either pull `is_con()` or `const_oop()` out of the input. I think we will bikeshed about the tests a bit. test/micro/org/openjdk/bench/jdk/incubator/vector/VectorExtractBenchmark.java line 34: > 32: @Warmup(iterations = 5, time = 1) > 33: @Measurement(iterations = 5, time = 1) > 34: @Fork(value = 1, jvmArgs = {"--add-modules=jdk.incubator.vector"}) Don't do 1 fork, do at least 3. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27113#pullrequestreview-3188769547 PR Review Comment: https://git.openjdk.org/jdk/pull/27113#discussion_r2324679427 From alanb at openjdk.org Fri Sep 5 10:32:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Sep 2025 10:32:10 GMT Subject: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 10:03:44 GMT, Aleksey Shipilev wrote: > Seeing these tests failing often now. I think I need a second reviewer to integrate this, to make testing cleaner. One Reviewer is okay here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27104#issuecomment-3257874725 From jpai at openjdk.org Fri Sep 5 10:36:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Sep 2025 10:36:09 GMT Subject: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:47:33 GMT, Aleksey Shipilev wrote: > GetStackTraceALotWhenPinned test times out every so often in GHA. > > The last sightings are on macos-aarch64: > > > 2025-09-04T10:41:29.357879Z => 87894 of 100000 > 2025-09-04T10:41:30.365534Z => 88105 of 100000 > Timeout signalled after 300 seconds > 2025-09-04T10:41:31.367068Z => 88298 of 100000 > 2025-09-04T10:41:32.377128Z => 88400 of 100000 > > 2025-09-03T10:08:37.713537Z => 74715 of 100000 > 2025-09-03T10:08:38.717750Z => 74818 of 100000 > Timeout signalled after 300 seconds > 2025-09-03T10:08:39.722960Z => 74922 of 100000 > 2025-09-03T10:08:40.726642Z => 75024 of 100000 > > > Looks like we are nearly there, just need fewer iterations. I think like with [JDK-8344577](https://bugs.openjdk.org/browse/JDK-8344577), we just need to extend the test check for AArch64 macs as well. > > Additional testing: > - [x] MacOS AArch64 server fastdebug, `java/lang/Thread/virtual/stress`, 10x Looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27104#pullrequestreview-3188841667 From shade at openjdk.org Fri Sep 5 10:58:22 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 Sep 2025 10:58:22 GMT Subject: Integrated: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:47:33 GMT, Aleksey Shipilev wrote: > GetStackTraceALotWhenPinned test times out every so often in GHA. > > The last sightings are on macos-aarch64: > > > 2025-09-04T10:41:29.357879Z => 87894 of 100000 > 2025-09-04T10:41:30.365534Z => 88105 of 100000 > Timeout signalled after 300 seconds > 2025-09-04T10:41:31.367068Z => 88298 of 100000 > 2025-09-04T10:41:32.377128Z => 88400 of 100000 > > 2025-09-03T10:08:37.713537Z => 74715 of 100000 > 2025-09-03T10:08:38.717750Z => 74818 of 100000 > Timeout signalled after 300 seconds > 2025-09-03T10:08:39.722960Z => 74922 of 100000 > 2025-09-03T10:08:40.726642Z => 75024 of 100000 > > > Looks like we are nearly there, just need fewer iterations. I think like with [JDK-8344577](https://bugs.openjdk.org/browse/JDK-8344577), we just need to extend the test check for AArch64 macs as well. > > Additional testing: > - [x] MacOS AArch64 server fastdebug, `java/lang/Thread/virtual/stress`, 10x This pull request has now been integrated. Changeset: 0dad3f1a Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/0dad3f1ae8d0c35c4b7a8188ad7854d01c7cd6b4 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27104 From shade at openjdk.org Fri Sep 5 10:58:22 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 Sep 2025 10:58:22 GMT Subject: RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64 In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:47:33 GMT, Aleksey Shipilev wrote: > GetStackTraceALotWhenPinned test times out every so often in GHA. > > The last sightings are on macos-aarch64: > > > 2025-09-04T10:41:29.357879Z => 87894 of 100000 > 2025-09-04T10:41:30.365534Z => 88105 of 100000 > Timeout signalled after 300 seconds > 2025-09-04T10:41:31.367068Z => 88298 of 100000 > 2025-09-04T10:41:32.377128Z => 88400 of 100000 > > 2025-09-03T10:08:37.713537Z => 74715 of 100000 > 2025-09-03T10:08:38.717750Z => 74818 of 100000 > Timeout signalled after 300 seconds > 2025-09-03T10:08:39.722960Z => 74922 of 100000 > 2025-09-03T10:08:40.726642Z => 75024 of 100000 > > > Looks like we are nearly there, just need fewer iterations. I think like with [JDK-8344577](https://bugs.openjdk.org/browse/JDK-8344577), we just need to extend the test check for AArch64 macs as well. > > Additional testing: > - [x] MacOS AArch64 server fastdebug, `java/lang/Thread/virtual/stress`, 10x OK, thanks, here goes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27104#issuecomment-3257939763 From rriggs at openjdk.org Fri Sep 5 14:17:10 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 5 Sep 2025 14:17:10 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Have you verified that the serialized streams in these new tests are identical to the hexformat versions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3258516580 From kevin.bourrillion at oracle.com Fri Sep 5 15:22:47 2025 From: kevin.bourrillion at oracle.com (Kevin Bourrillion) Date: Fri, 5 Sep 2025 15:22:47 +0000 Subject: StableValue and non-deterministic iteration order In-Reply-To: References: Message-ID: Just as a corroborating data point, it?s banned at my previous company too, and this is a big reason why. Deterministic iteration is a very good thing. (Personal opinion: I?ve come to view non-deterministic iteration as a risky optimization in general, that is usually not called for.) From: core-libs-dev on behalf of Stephen Colebourne Date: Friday, September 5, 2025 at 12:13?AM To: core-libs-dev Subject: StableValue and non-deterministic iteration order In summary, the current Map.of() is a bit of a hand grenade IMO, and something I pretty much banned at my previous company. Which is a problem given its key role in StableValue. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihse at openjdk.org Fri Sep 5 15:43:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 5 Sep 2025 15:43:32 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp Message-ID: Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. ------------- Commit messages: - Fix syntax error - Don't use $(if ...) for KEYS. - Move weird characters in template expansion from command line to the template itself - Merge branch 'master' into cleanup-spp-gensrc - 8366837: Clean up gensrc by spp.Spp Changes: https://git.openjdk.org/jdk/pull/27078/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27078&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366837 Stats: 1321 lines in 9 files changed: 523 ins; 562 del; 236 mod Patch: https://git.openjdk.org/jdk/pull/27078.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27078/head:pull/27078 PR: https://git.openjdk.org/jdk/pull/27078 From ihse at openjdk.org Fri Sep 5 15:43:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 5 Sep 2025 15:43:32 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: <3R3SyNx6jYRhyK-xJwmoscTX2oSAV0zzQWHW2AYDf-A=.6bff4b0c-2e79-4648-a7d9-a42a559c4b48@github.com> On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. I have verified that the generated java source code in gensrc is byte-by-byte identical with and without this patch. That is really all that is needed in terms of correctness, but to make sure I do not run into some unexpected problem I am also running a confirmation round on our internal CI. Hm, something is messing up the command lines on the GHA hosts. Funny, I did not see it when testing elsewhere. I'll look into it. For the record: the changes in the X-Coder template means that additional empty lines will be inserted in the generated source. This has no real effect on anything substantial, but it means that line numbers change, which make a complete byte-by-byte comparison fail for anything that is dependent on these classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3250651080 PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3250722749 PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3258508787 From ryan at iernst.net Fri Sep 5 15:45:14 2025 From: ryan at iernst.net (Ryan Ernst) Date: Fri, 5 Sep 2025 08:45:14 -0700 Subject: StableValue and non-deterministic iteration order In-Reply-To: References: Message-ID: <419F2BA6-CBBA-43E9-9DE4-73B41542CF68@iernst.net> The iteration order is deterministic. The problem raised in that thread was that the seed is hidden and uncontrollable. IMO if you want a Map that has order, use a LinkedHashMap (or the idea is SequencedMap.of is also appealing). However, even if you don?t want to depend on iteration order, sometimes there are bugs that unintentionally depend on that order, so it would still be great to control the seed in order to have reproducibility in tests. > On Sep 5, 2025, at 08:23, Kevin Bourrillion wrote: > > ? > Just as a corroborating data point, it?s banned at my previous company too, and this is a big reason why. Deterministic iteration is a very good thing. (Personal opinion: I?ve come to view non-deterministic iteration as a risky optimization in general, that is usually not called for.) > > > From: core-libs-dev on behalf of Stephen Colebourne > Date: Friday, September 5, 2025 at 12:13?AM > To: core-libs-dev > Subject: StableValue and non-deterministic iteration order > > > In summary, the current Map.of() is a bit of a hand grenade IMO, and > something I pretty much banned at my previous company. Which is a > problem given its key role in StableValue. > > Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Fri Sep 5 15:58:19 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 15:58:19 GMT Subject: RFR: 8365428: Unclear comments on java.lang.invoke Holder classes [v4] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 00:00:34 GMT, Chen Liang wrote: >> java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. >> >> Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". >> >> However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. >> >> To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Jorn review Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27010#issuecomment-3258862438 From liach at openjdk.org Fri Sep 5 15:58:20 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 15:58:20 GMT Subject: Integrated: 8365428: Unclear comments on java.lang.invoke Holder classes In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 19:17:23 GMT, Chen Liang wrote: > java.lang.invoke has a few Holder classes in DirectMethodHandle, DelegatingMethodHandle, Invokers, and LambdaForm. > > Currently, the comments simply refer to "Placeholder for xxx generated ahead-of-time". > > However, they carry executed bytecode and show up in flame graphs. The current comments are definitely not sufficient for their details and purposes. > > To address these shortcomings, I improved the comments on the Holder classes and GenerateJLIClassesHelper to briefly describe the generation process. In addition, I improved the comments on BoundMethodHandle to provide a more efficient overview. This pull request has now been integrated. Changeset: 9f4d5b23 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/9f4d5b2398cb925ec1a66f9f7676b76c99ff7b62 Stats: 147 lines in 7 files changed: 109 ins; 8 del; 30 mod 8365428: Unclear comments on java.lang.invoke Holder classes Reviewed-by: iklam, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/27010 From liach at openjdk.org Fri Sep 5 16:03:12 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 16:03:12 GMT Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build In-Reply-To: References: <2REfnawHIfGgnFBrEQMb2vDBkUjLNnzbFRV726KSOJ0=.c7a05f23-3268-4261-8a8a-a503824a8fc0@github.com> Message-ID: On Tue, 2 Sep 2025 15:24:07 GMT, Paul Sandoz wrote: >> @PaulSandoz Do you know if there was/is a particular reason for not generating the VarHandle guards as part of the build? > >> @PaulSandoz Do you know if there was/is a particular reason for not generating the VarHandle guards as part of the build? > > At the time there were other priorities and we did not know what the frequency of updates might be, but we left gen code in place just in case (and did use it occasionally). I think this PR is good, addressing tech debt. Can @PaulSandoz or @JornVernee re-review this patch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27009#issuecomment-3258882442 From liach at openjdk.org Fri Sep 5 16:03:11 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 16:03:11 GMT Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed [v2] In-Reply-To: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> References: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> Message-ID: On Thu, 4 Sep 2025 18:24:57 GMT, Matias Saavedra Silva wrote: >> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should be handled by the stack map table and its rules for `uninitializedThis`. Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can be removed. Verified with tier1-5 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Fixed copyright Do we need a test case emulating the scenario described by JVMS, to ensure the particular scenario once covered by ends_in_athrow is still covered? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27107#issuecomment-3258880424 From shaunspiller at gmail.com Fri Sep 5 16:05:17 2025 From: shaunspiller at gmail.com (Shaun Spiller) Date: Fri, 5 Sep 2025 17:05:17 +0100 Subject: Excessive copying of Collection.toArray() In-Reply-To: <4543dc86-0de7-47dd-8e3d-8872005d4d89@oracle.com> References: <4543dc86-0de7-47dd-8e3d-8872005d4d89@oracle.com> Message-ID: On Thu, 4 Sept 2025 at 03:17 UTC, Stuart Marks wrote: > > Hi Shaun, > > You got pretty far with your analysis; congratulations! Thank you!! > You already proposed and knocked down the "obvious solution" which is to trust JDK > classes (which are loaded by the boot classloader). Similar simple solutions, such > as an allowlist with `instanceof` checks, can be defeated by subclassing. Those two checks `&&`ed together would work, though, I think? Here's a rough census of some ways to identify "trusted" collection classes: * ClassLoader -- not selective enough on its own * instanceof ClassName, combined with classloader check -- has the hazard of being inheritable within the JDK; won't work for private collection classes; O(n) where n is the number of classes checked * instanceof MarkerInterface, combined with classloader check -- has the hazard of being inheritable within the JDK; presence of marker interface would be visible outside the JDK via reflection, which is inelegant but mostly harmless * .getClass().getInterfaces().contains(MarkerInterface) -- non-heritable version of instanceof * A centrally-maintained table of trusted Class objects -- non-heritable; won't work for private collection classes; causes early class loading * A centrally-maintained table of trusted class *names* -- avoids premature class loading; a brittle binding because it's not checked at compile time * Marker annotation on class -- could be very tidy but performance is unclear and might have bootstrapping problems?? * Each participating class uses a static initializer to call a JDK internal method to add its Class object to a dynamically populated table of trusted classes -- extra complexity of dynamic table but I believe it could work * more??? It's something that would need checking by a security expert. Any of the table-based solutions have the potential to become quite large. If any JDK Collection is potentially allowed to join the "trusted" club, that's a huge type hierarchy. So there is the question of how to achieve O(1) lookup. I would instinctively reach for an IdentityHashMap but maybe that's not bootstrap-friendly, I don't know. Or maybe the trusted club really should just be very small and insular. Trading security for performance is short-sighted. Also, I see no options for anonymous collection classes to participate, except stop being anonymous. Anonymous classes don't have proper names, can't implement extra interfaces, can't have class annotations, can't refer to their class object in a static initializer, etc. There are very few of these, although java.util.AbstractMap.keySet() is an example. > But this would still leave non-JDK classes out in the cold. An arrangement that > could work would be to have some construct that allows the creation of and writing > to an array, but which precludes the possibility of retaining a reference to the > array (or perhaps merely preventing writes to it after a certain point). One could > imagine a library construct that implements this. Of course it would require classes > to opt into this arrangement. Ordinary implementors of toArray() would still suffer > an extra copy. It's remarkable, because at its core it's such a basic thing for a computer program to do: copy a list and stick it in another. The bugs that result are highly non-obvious. When the need is basic but the correct solution is subtle, it's the kind of bug that will keep happening. Not just with ArrayList, but with anything conceptually similar. It's like Java's equivalent of a buffer overflow. The language design makes it inevitable for this to go wrong. I think the simple, widely-applicable List.of and friends are very helpful here because they make it easy for applications to move data around securely and immutably, to do things the right way even if they didn't realize there was a wrong way. If there were also a solution for primitives -- frozen arrays or primitive generic lists -- that could cover some more ground. Around 2010, I wrote a terrible hack for the usual wrong reason (performance): there was a ByteArrayOutputStream with a large blob of data, and I wanted to avoid the clone cost of calling toByteArray(), so I did `baos.writeTo(new OutputStream() { ... })` with an overridden `OutputStream.write` that simply exfiltrated the passed buffer argument -- letting me access, even modify, the internal buffer of the ByteArrayOutputStream. My intent wasn't nefarious. But the general principle is this: arrays are dangerous. They're always mutable, widely shared around, and you can't stop someone retaining a reference, eventually causing problems deliberately or accidentally. I had a vision similar to what you describe: Some kind of library class that takes an array and provides a temporary, closeable view of a slice of it, so access can be shared (read-only, write-only, or read-write) inside an enforceable scope. But I think such a class would be too cumbersome to see wide use unless its views could be typecast to a "normal" array type. Then it could be used with traditional APIs like `Collection.toArray(Object[])`, or `OutputStream.write(byte[])`. But that turns a simple utility class into a serious language and VM engineering project. > But maybe this is overkill, and the best is the enemy of the good. Perhaps we could > add a short allowlist that contains just the most frequently-used JDK classes. This > wouldn't be exhaustive, but it could help the situation by covering more of the > common cases. Yes, 100%. The Pareto principle applies; most of the available benefit would come from just a few cases. It would be nice if at least ArrayList and List.of could trust each other, providing a smooth transition between the mutable and immutable realms. > > Also, the knowledge of why the defensive clone is made at all, and why > > it must be of type Object[] and not a covariant subclass, these are > > currently arcane secrets held only by those who know the history of > > the associated bug reports. That's another part of why I argue for a > > central method that can be named and discussed. > The need for an extra defensive copy was established and fixed via the security > vulnerability process and as such, all discussion of it was embargoed. Sorry. > [...] > But I think you've discerned the issue yourself already. In 2014 I sent in a bug report, JDK-8048200, the "Widget" example showing some toArray() mischief. If I recall correctly, it was closed as a duplicate of some earlier report or reports, ultimately disregarded because the exploit did not seem potent enough to justify the cost of blocking it. Years later I noticed the change to ArrayList, and discovered that my bug report and dupes had been quietly disappeared from the web. I can't even see the title. So I realized there had been some kind of blowup. :) Anyway, what I was wanting to say by complaining about the "arcane secrets" is simply it's another reason why a documented method is beneficial, to leave signposts in the code when dragons are nearby. Another 50 years from now, those classes will still be in use. If someone in the future reworking PriorityBlockingQueue sees this: if (c.getClass() != java.util.ArrayList.class) es = Arrays.copyOf(es, n, Object[].class); they won't appreciate the detailed thought behind those two lines unless they decide to do some extensive digital archeology. A commented method can refer to past bug reports, ward off future bugs, and help promote the right way of doing things in general. I've read your blog post on the subject of "The Importance of Writing Stuff Down" :) I imagine it was initially undesirable to draw attention to the code in an open-source security patch, but it's been 5 years. ~ From naoto at openjdk.org Fri Sep 5 16:16:12 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 16:16:12 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Although the existing tests are old and not run, I think the existing data can be reused. You can create overload for `deSer()` for these and test them. I believe they are the real serialized objects from the older releases, so I believe testing them still have value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3258921072 From jlu at openjdk.org Fri Sep 5 16:37:08 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 16:37:08 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: <6RyH1eZqhrpM8vWDsIQ0ZcW7Qn35RECuAOyNPhbES2I=.0450ecca-59d3-4859-b658-34bdb74a9dde@github.com> On Fri, 5 Sep 2025 14:14:48 GMT, Roger Riggs wrote: > Have you verified that the serialized streams in these new tests are identical to the hexformat versions? I looked at the respective Serialization save files and what was being tested in the load files to determine the configuration of the replacement tests. I stepped through the tests with a debugger to make sure the data read from the stream that was being tested was accurate with what was indicated in the save file. I do not expect the streams themselves to be identical (since the new ones are mocked), but rather the invariants being tested should be the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3258975202 From jlu at openjdk.org Fri Sep 5 16:41:10 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 16:41:10 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 16:13:50 GMT, Naoto Sato wrote: > Although the existing tests are old and not run, I think the existing data can be reused. You can create overload for `deSer()` for these and test them. I believe they are the real serialized objects from the older releases, so I believe testing them still have value. The new tests mock these streams so that we could do away with relying on the hex dump files (which required a user to navigate to the unused save file to determine how the stream was created). What is being tested should be the same for the mocked stream and the original stream itself. However, if it is desirable to test the exact streams from older releases, I can bring the data files back and test their streams directly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3258986668 From kevin.bourrillion at oracle.com Fri Sep 5 16:44:53 2025 From: kevin.bourrillion at oracle.com (Kevin Bourrillion) Date: Fri, 5 Sep 2025 16:44:53 +0000 Subject: [External] : Re: StableValue and non-deterministic iteration order In-Reply-To: <419F2BA6-CBBA-43E9-9DE4-73B41542CF68@iernst.net> References: <419F2BA6-CBBA-43E9-9DE4-73B41542CF68@iernst.net> Message-ID: Sure, I just write ?deterministic based on a hidden variable? more concisely as ?non-deterministic?; they mean about the same thing. When you say ?if you want a Map that has order, use?? this illustrates the notion that things should be faster and less safe by default, and users can explicitly opt into more safety/predictability when they know they need it. I personally feel history has proven this approach doesn?t work out well. From: Ryan Ernst Date: Friday, September 5, 2025 at 8:45?AM To: Kevin Bourrillion Cc: Stephen Colebourne , core-libs-dev Subject: [External] : Re: StableValue and non-deterministic iteration order The iteration order is deterministic. The problem raised in that thread was that the seed is hidden and uncontrollable. IMO if you want a Map that has order, use a LinkedHashMap (or the idea is SequencedMap.of is also appealing). However, even if you don?t want to depend on iteration order, sometimes there are bugs that unintentionally depend on that order, so it would still be great to control the seed in order to have reproducibility in tests. On Sep 5, 2025, at 08:23, Kevin Bourrillion wrote: ? Just as a corroborating data point, it?s banned at my previous company too, and this is a big reason why. Deterministic iteration is a very good thing. (Personal opinion: I?ve come to view non-deterministic iteration as a risky optimization in general, that is usually not called for.) From: core-libs-dev on behalf of Stephen Colebourne Date: Friday, September 5, 2025 at 12:13?AM To: core-libs-dev Subject: StableValue and non-deterministic iteration order In summary, the current Map.of() is a bit of a hand grenade IMO, and something I pretty much banned at my previous company. Which is a problem given its key role in StableValue. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From psandoz at openjdk.org Fri Sep 5 16:46:12 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 5 Sep 2025 16:46:12 GMT Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build [v2] In-Reply-To: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com> References: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com> Message-ID: On Tue, 2 Sep 2025 22:20:26 GMT, Chen Liang wrote: >> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class. >> >> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too. >> >> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData. >> >>
>> >> Diff from new to old (backwards): >> >> >> >> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> index 13ef65b..49408a2 100644 >> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java >> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer; >> import jdk.internal.vm.annotation.ForceInline; >> import jdk.internal.vm.annotation.Hidden; >> >> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator. >> -// Do not edit! >> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit. >> @AOTSafeClassInitializer >> final class VarHandleGuards { >> >> >> >>
>> >> Testing: java/lang/invoke. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Preexisting typos > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/build-vhguards > - Restore order > - 8366455: Move VarHandles.GuardMethodGenerator to execute on build Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27009#pullrequestreview-3190082576 From forax at univ-mlv.fr Fri Sep 5 17:12:56 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 5 Sep 2025 19:12:56 +0200 (CEST) Subject: StableValue and non-deterministic iteration order In-Reply-To: References: Message-ID: <1468138613.23853829.1757092376100.JavaMail.zimbra@univ-eiffel.fr> For me, Map.copyOf() is worst, it is designed to do defensive copy, but you can not use it to do a defensive copy because the user of your library may rely on the Map iteration order.. R?mi > From: "Kevin Bourrillion" > To: "Stephen Colebourne" , "core-libs-dev" > > Sent: Friday, September 5, 2025 5:22:47 PM > Subject: Re: StableValue and non-deterministic iteration order > Just as a corroborating data point, it?s banned at my previous company too, and > this is a big reason why. Deterministic iteration is a very good thing. > (Personal opinion: I?ve come to view non-deterministic iteration as a risky > optimization in general, that is usually not called for.) > From: core-libs-dev on behalf of Stephen > Colebourne > Date: Friday, September 5, 2025 at 12:13 AM > To: core-libs-dev > Subject: StableValue and non-deterministic iteration order > In summary, the current Map.of() is a bit of a hand grenade IMO, and > something I pretty much banned at my previous company. Which is a > problem given its key role in StableValue. > Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmesnik at openjdk.org Fri Sep 5 17:15:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 5 Sep 2025 17:15:13 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3190212809 From ihse at openjdk.org Fri Sep 5 17:18:15 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 5 Sep 2025 17:18:15 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: <3GbZE6bnaw9k543kmYqbPXW-sTX_6-ToUsorSTpEJ-0=.b6fb443e-9a13-4478-830f-633ec21dfb47@github.com> On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. This has passed Oracle internal CI testing for "builds-infra" tier 1-5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3259183136 From naoto at openjdk.org Fri Sep 5 17:42:09 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 17:42:09 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 16:38:06 GMT, Justin Lu wrote: > However, if it is desirable to test the exact streams from older releases, I can bring the data files back and test their streams directly. Yes, I think so. Unless there is any specific reason to remove tests, it is the main purpose for these *regression* tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3259242350 From emcmanus at google.com Fri Sep 5 18:57:40 2025 From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=) Date: Fri, 5 Sep 2025 11:57:40 -0700 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: As promised, Kurt and I have examined some of the uses of our Durations.MAX constant. This is a summary of what we see in a random sample of 30 out of about 700 usages in Google's (giant) codebase. First, about half of the usages specifically concern deadlines. Many of them involve a method that sets an RPC deadline and where it is explicitly documented that you should use Durations.MAX to mean no deadline (or equivalently, infinite deadline). Several other usages concern deadline-adjacent concepts such as time-to-live or cache expiration delay. A number of usages specifically compare a Duration against Durations.MAX to recognize the "infinite duration" value. One usage uses our internal Sleeper interface to do sleeper.sleep(Durations.MAX), for an indefinite sleep (until interrupted). In a couple of places, there is a maximum allowed Duration for some operation, and a user-supplied Duration value is capped by this maximum. When no maximum is needed, the cap is Durations.MAX. This is similar to the "sentinel" use case I mentioned earlier. One case is using Durations.MAX in a test, to ensure that a function works correctly for all Duration values including the largest one. It is testing a Kotlin extension function that allows you to write e.g. 5.minutes: val n = Durations.MAX.toMinutes() assertThat(n.minutes).isEqualTo(Duration.ofMinutes(n)) assertFailsWith { (n + 1).minutes } In summary, I think the most interesting use cases fall into these categories: - to express an effectively-infinite Duration, possibly accompanied by special-case logic to optimize the exact value Durations.MAX; - to express the absence of an optional cap on a user-supplied Duration value; - to test that code works correctly even with extreme Duration values. Of these, the first is potentially fragile because of the overflow problems we discussed. The other two seem unproblematic, though. On Thu, 4 Sept 2025 at 15:02, ?amonn McManus wrote: > Two typical use cases: > > // 1. Sentinel > Duration min = Duration.MAX; > for (var foo : something()) { > if (foo.duration().compareTo(min) < 0) { > min = foo.duration(); > } > } > > // 2. "Forever" > void frob(Optional optionalTimeout) { > Duration timeout = optionalTimeout.orElse(Duration.MAX); > Instant start = Instant.now(); > boolean done = false; > while (!done && startTime.until(Instant.now()).compareTo(timeout) < 0) > {...} > } > > The second case illustrates why this is potentially a bit delicate. You > better not write this: > > void frob(Optional optionalTimeout) { > Duration timeout = optionalTimeout.orElse(Duration.MAX); > Instant deadline = Instant.now().plus(timeout); // oops > boolean done = false; > while (!done && Instant.now().isBefore(deadline)) {...} > } > > Like Kevin, I am skeptical about Duration.MIN. If it means the most > negative Duration, that is just Duration.MAX.negated(); and if it means the > smallest positive Duration, that is just Duration.ofNanos(1). > > On Wed, 3 Sept 2025 at 18:32, Roger Riggs wrote: > >> Hi, >> >> I'd be interested in the range of use cases for Duration.MAX or MIN. >> >> But for deadlines, I think the code should compute the deadline from a >> Duration of its choice based on the use. >> Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores >> information about the particular use that is relevant. Its just sloppy code >> that doesn't bother to express how long is long enough to meet operational >> parameters. >> >> YMMV, Roger >> >> On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: >> >> Duration.MIN is a whole 'nother bag of worms, because Durations are >> signed (they can be positive or negative...or zero). Internally we also >> have Durations.MIN, but it's not public ... and along with it, I left >> myself a helpful note about naming: >> >> /** The minimum supported {@code Duration}, approximately -292 billion >> years. */ >> // Note: before making this constant public, consider that "MIN" might >> not be a great name (not >> // everyone knows that Durations can be negative!). >> static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); >> >> This reminds me of Double.MIN_VALUE (which is the smallest _positive_ >> double value) --- we've seen Double.MIN_VALUE misused so much that we >> introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large >> percent of Double.MIN_VALUE users actually want the smallest possible >> negative value, aka -Double.MAX_VALUE. >> >> If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), >> but rather Duration.ofSeconds(Long.MIN_VALUE). >> >> On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: >> >>> If you ask me, I don?t find it very useful, It won?t work for >>> arithmetrics, even the APIs would have a hard time using it (how do you >>> express the deadline) and APIs with a timeout parameter do have a good >>> reason for it, better pick ?possible? values for better self healing and >>> unstuck of systems. In fact I would err on the smaller side in combination >>> with expecting spurious wakeups. >>> >>> BTW, when you introduce MIN as well, maybe also think about min >>> precision, min delta or such. Will it always be 1 nano? >>> >>> Gru?, >>> Bernd >>> -- >>> https://bernd.eckenfels.net >>> ------------------------------ >>> *Von:* core-libs-dev im Auftrag von >>> Pavel Rappo >>> *Gesendet:* Donnerstag, September 4, 2025 12:41 AM >>> *An:* Kurt Alfred Kluever >>> *Cc:* Stephen Colebourne ; core-libs-dev < >>> core-libs-dev at openjdk.org> >>> *Betreff:* Re: Duration.MAX_VALUE >>> >>> This is useful; thanks. It would be good to see more of your data. >>> >>> My use case is also duration which practically means **forever**. I >>> pass it to methods that accept timeouts, and expect these methods to >>> correctly interpret it. >>> >>> One example of a practical interpretation is >>> java.util.concurrent.TimeUnit.convert(Duration). This method never >>> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is >>> roughly 292 years. >>> >>> Would I be okay, if the proposed duration didn't reflect **forever** >>> but instead reflected **long enough**? I think so. But it still >>> somehow feels wrong to make it less than maximum representable value. >>> >>> Personally, I'm not interested in calendar arithmetic, that is, in >>> adding or subtracting durations. Others might be, and that's okay and >>> needs to be factored in. For better or worse, java.time made a choice >>> to be unforgiving in regard to overflow and is very upfront about it. >>> It's not only proposed Duration.MAX. The same thing happens if you try >>> this >>> >>> Instant.MAX.toEpochMilli() >>> >>> I guess my point is that doing calendar arithmetic on an unknown value >>> is probably wrong. Doing it on a known huge/edge-case value is surely >>> wrong. So back to your data. I would be interested to see what >>> triggers overflows for your Durations.MAX. >>> >>> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever >>> wrote: >>> > >>> > Hi all, >>> > >>> > Internally at Google, we've had a Durations.MAX constant exposed for >>> the past 7 years. It now has about 700 usages across our depot, which I can >>> try to categorize (at a future date). >>> > >>> > While I haven't performed that analysis yet, I think exposing this >>> constant was a bit of a mistake. People seem to want to use MAX to mean >>> "forever" (often in regards to an RPC deadline). This works fine as long as >>> every single layer that touches the deadline is very careful about >>> overflow. The only reasonable thing you can do with MAX is compareTo() and >>> equals(). Attempting to do any simple math operation (e.g., now+deadline) >>> is going to explode. Additionally, decomposing Duration.MAX explodes for >>> any sub-second precision (e.g., toMillis()). >>> > >>> > As we dug into this, another proposal came up which was something like >>> Durations.VERY_LONG. This duration would be longer than any reasonable >>> finite duration but not long enough to cause an overflow when added to any >>> reasonable time. E.g., a million years would probably satisfy both >>> criteria. This would mean math operations and decompositions won't explode >>> (well, microseconds and nanoseconds still would), and it could safely be >>> used as a relative timeout. >>> > >>> > As I mentioned above, I'd be happy to try to categorize a sample of >>> our 700 existing usages if folks think that would be useful for this >>> proposal. >>> > >>> > Thanks, >>> > >>> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem >>> team) >>> > >>> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo >>> wrote: >>> >> >>> >> If I understood you correctly, you think we should also add >>> >> Duration.MIN. If so, what use case do you envision for it? Or we add >>> >> if purely for symmetry with Instant? >>> >> >>> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo >>> wrote: >>> >> > >>> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne < >>> scolebourne at joda.org> wrote: >>> >> > > >>> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! >>> >> > > The constants would be MAX/MIN as per classes like Instant. >>> >> > > Stephen >>> >> > >>> >> > I thought that naming could be tricky :) The public constant >>> >> > Duration.ZERO and the public method isZero() are already there. >>> >> > However, it does not preclude us from naming a new constant MAX. >>> > >>> > >>> > >>> > -- >>> > kak >>> >>> >> >> -- >> kak >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5281 bytes Desc: S/MIME Cryptographic Signature URL: From stuart.marks at oracle.com Fri Sep 5 19:00:48 2025 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 5 Sep 2025 12:00:48 -0700 Subject: StableValue and non-deterministic iteration order In-Reply-To: References: Message-ID: <0a860156-16bb-45fa-8f92-6c14e910b6d7@oracle.com> On 9/5/25 12:12 AM, Stephen Colebourne wrote: > Back in March 2023 there was a discussion about the non-deterministic > iteration order of Map.of() and friends: > https://mail.openjdk.org/pipermail/core-libs-dev/2023-March/102865.html > > It feels like this discussion should be revisited now that we have > StableValue. Map.of() is one of the few ways (along with method > references and records) that we have at the moment to ensure a chain > of trust through for the JVM so it can constant fold. This should (if > people are aware) push more people to use Map.of() and friends. Hi Stephen, What's the connection between Map.of()'s randomized encounter order and StableValue or the JIT's ability to constant-fold? Are you observing that randomized encounter order precludes constant folding? Or are you saying that something should change near the (preview) StableValue.map() API? For example, that it should specify a particular encounter order, or that its API signature should change? s'marks From emcmanus at google.com Fri Sep 5 19:13:36 2025 From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=) Date: Fri, 5 Sep 2025 12:13:36 -0700 Subject: Duration.MAX_VALUE In-Reply-To: References: Message-ID: I wrote: > Like Kevin, I am skeptical about Duration.MIN. If it means the most negative Duration, that is just Duration.MAX.negated(); and if it means the smallest positive Duration, that is just Duration.ofNanos(1). Yesterday's message from Pavel Rappo shows that the most negative Duration is actually Duration.MAX.negated().minus(Duration.ofNanos(1)), which I think is pretty sad. So that is maybe *some* justification for a hypothetical Duration.MIN, or better Duration.MOST_NEGATIVE. I don't think it would see much use, though. On Thu, 4 Sept 2025 at 15:02, ?amonn McManus wrote: > Two typical use cases: > > // 1. Sentinel > Duration min = Duration.MAX; > for (var foo : something()) { > if (foo.duration().compareTo(min) < 0) { > min = foo.duration(); > } > } > > // 2. "Forever" > void frob(Optional optionalTimeout) { > Duration timeout = optionalTimeout.orElse(Duration.MAX); > Instant start = Instant.now(); > boolean done = false; > while (!done && startTime.until(Instant.now()).compareTo(timeout) < 0) > {...} > } > > The second case illustrates why this is potentially a bit delicate. You > better not write this: > > void frob(Optional optionalTimeout) { > Duration timeout = optionalTimeout.orElse(Duration.MAX); > Instant deadline = Instant.now().plus(timeout); // oops > boolean done = false; > while (!done && Instant.now().isBefore(deadline)) {...} > } > > Like Kevin, I am skeptical about Duration.MIN. If it means the most > negative Duration, that is just Duration.MAX.negated(); and if it means the > smallest positive Duration, that is just Duration.ofNanos(1). > > On Wed, 3 Sept 2025 at 18:32, Roger Riggs wrote: > >> Hi, >> >> I'd be interested in the range of use cases for Duration.MAX or MIN. >> >> But for deadlines, I think the code should compute the deadline from a >> Duration of its choice based on the use. >> Maybe there is a use for Duration.REALLY_BIG or _SMALL, but that ignores >> information about the particular use that is relevant. Its just sloppy code >> that doesn't bother to express how long is long enough to meet operational >> parameters. >> >> YMMV, Roger >> >> On 9/3/25 8:21 PM, Kurt Alfred Kluever wrote: >> >> Duration.MIN is a whole 'nother bag of worms, because Durations are >> signed (they can be positive or negative...or zero). Internally we also >> have Durations.MIN, but it's not public ... and along with it, I left >> myself a helpful note about naming: >> >> /** The minimum supported {@code Duration}, approximately -292 billion >> years. */ >> // Note: before making this constant public, consider that "MIN" might >> not be a great name (not >> // everyone knows that Durations can be negative!). >> static final Duration MIN = Duration.ofSeconds(Long.MIN_VALUE); >> >> This reminds me of Double.MIN_VALUE (which is the smallest _positive_ >> double value) --- we've seen Double.MIN_VALUE misused so much that we >> introduced Doubles.MIN_POSITIVE_VALUE as a more descriptive alias. A large >> percent of Double.MIN_VALUE users actually want the smallest possible >> negative value, aka -Double.MAX_VALUE. >> >> If we introduce Duration.MIN, I hope it would not be Duration.ofNanos(1), >> but rather Duration.ofSeconds(Long.MIN_VALUE). >> >> On Wed, Sep 3, 2025 at 7:59?PM ecki wrote: >> >>> If you ask me, I don?t find it very useful, It won?t work for >>> arithmetrics, even the APIs would have a hard time using it (how do you >>> express the deadline) and APIs with a timeout parameter do have a good >>> reason for it, better pick ?possible? values for better self healing and >>> unstuck of systems. In fact I would err on the smaller side in combination >>> with expecting spurious wakeups. >>> >>> BTW, when you introduce MIN as well, maybe also think about min >>> precision, min delta or such. Will it always be 1 nano? >>> >>> Gru?, >>> Bernd >>> -- >>> https://bernd.eckenfels.net >>> ------------------------------ >>> *Von:* core-libs-dev im Auftrag von >>> Pavel Rappo >>> *Gesendet:* Donnerstag, September 4, 2025 12:41 AM >>> *An:* Kurt Alfred Kluever >>> *Cc:* Stephen Colebourne ; core-libs-dev < >>> core-libs-dev at openjdk.org> >>> *Betreff:* Re: Duration.MAX_VALUE >>> >>> This is useful; thanks. It would be good to see more of your data. >>> >>> My use case is also duration which practically means **forever**. I >>> pass it to methods that accept timeouts, and expect these methods to >>> correctly interpret it. >>> >>> One example of a practical interpretation is >>> java.util.concurrent.TimeUnit.convert(Duration). This method never >>> overflows; instead, it caps at Long.MAX_VALUE nanoseconds, which is >>> roughly 292 years. >>> >>> Would I be okay, if the proposed duration didn't reflect **forever** >>> but instead reflected **long enough**? I think so. But it still >>> somehow feels wrong to make it less than maximum representable value. >>> >>> Personally, I'm not interested in calendar arithmetic, that is, in >>> adding or subtracting durations. Others might be, and that's okay and >>> needs to be factored in. For better or worse, java.time made a choice >>> to be unforgiving in regard to overflow and is very upfront about it. >>> It's not only proposed Duration.MAX. The same thing happens if you try >>> this >>> >>> Instant.MAX.toEpochMilli() >>> >>> I guess my point is that doing calendar arithmetic on an unknown value >>> is probably wrong. Doing it on a known huge/edge-case value is surely >>> wrong. So back to your data. I would be interested to see what >>> triggers overflows for your Durations.MAX. >>> >>> On Wed, Sep 3, 2025 at 8:45?PM Kurt Alfred Kluever >>> wrote: >>> > >>> > Hi all, >>> > >>> > Internally at Google, we've had a Durations.MAX constant exposed for >>> the past 7 years. It now has about 700 usages across our depot, which I can >>> try to categorize (at a future date). >>> > >>> > While I haven't performed that analysis yet, I think exposing this >>> constant was a bit of a mistake. People seem to want to use MAX to mean >>> "forever" (often in regards to an RPC deadline). This works fine as long as >>> every single layer that touches the deadline is very careful about >>> overflow. The only reasonable thing you can do with MAX is compareTo() and >>> equals(). Attempting to do any simple math operation (e.g., now+deadline) >>> is going to explode. Additionally, decomposing Duration.MAX explodes for >>> any sub-second precision (e.g., toMillis()). >>> > >>> > As we dug into this, another proposal came up which was something like >>> Durations.VERY_LONG. This duration would be longer than any reasonable >>> finite duration but not long enough to cause an overflow when added to any >>> reasonable time. E.g., a million years would probably satisfy both >>> criteria. This would mean math operations and decompositions won't explode >>> (well, microseconds and nanoseconds still would), and it could safely be >>> used as a relative timeout. >>> > >>> > As I mentioned above, I'd be happy to try to categorize a sample of >>> our 700 existing usages if folks think that would be useful for this >>> proposal. >>> > >>> > Thanks, >>> > >>> > -Kurt Alfred Kluever (on behalf of Google's Java and Kotlin Ecosystem >>> team) >>> > >>> > On Wed, Sep 3, 2025 at 1:53?PM Pavel Rappo >>> wrote: >>> >> >>> >> If I understood you correctly, you think we should also add >>> >> Duration.MIN. If so, what use case do you envision for it? Or we add >>> >> if purely for symmetry with Instant? >>> >> >>> >> On Wed, Sep 3, 2025 at 6:43?PM Pavel Rappo >>> wrote: >>> >> > >>> >> > On Wed, Sep 3, 2025 at 6:06?PM Stephen Colebourne < >>> scolebourne at joda.org> wrote: >>> >> > > >>> >> > > Hmm, yes. Not sure why that didn't get added in Java 8! >>> >> > > The constants would be MAX/MIN as per classes like Instant. >>> >> > > Stephen >>> >> > >>> >> > I thought that naming could be tricky :) The public constant >>> >> > Duration.ZERO and the public method isZero() are already there. >>> >> > However, it does not preclude us from naming a new constant MAX. >>> > >>> > >>> > >>> > -- >>> > kak >>> >>> >> >> -- >> kak >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5281 bytes Desc: S/MIME Cryptographic Signature URL: From scolebourne at joda.org Fri Sep 5 19:15:45 2025 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 5 Sep 2025 20:15:45 +0100 Subject: StableValue and non-deterministic iteration order In-Reply-To: <0a860156-16bb-45fa-8f92-6c14e910b6d7@oracle.com> References: <0a860156-16bb-45fa-8f92-6c14e910b6d7@oracle.com> Message-ID: On Fri, 5 Sept 2025 at 20:00, Stuart Marks wrote: > What's the connection between Map.of()'s randomized encounter order and StableValue > or the JIT's ability to constant-fold? Are you observing that randomized encounter > order precludes constant folding? Or are you saying that something should change > near the (preview) StableValue.map() API? For example, that it should specify a > particular encounter order, or that its API signature should change? The recent JVMLS talk indicated that a StableValue needs to be rooted in a field that the JVM can trust does not change (so that constant folding can occur). This includes static fields, record fields, method references, and List.of()/Map.of(). As such, the connection between the randomized order and StableValue is that more devs are going to be pushed to use Map.of(). (unless I misunderstand, StableValue.map() cannot be used to create an ordered map) Stephen From rriggs at openjdk.org Fri Sep 5 19:18:09 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 5 Sep 2025 19:18:09 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Yes, the purpose of the hex dumps is to test exactly the stream produced by earlier versions. They should be retained. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3259470579 From dlong at openjdk.org Fri Sep 5 19:47:08 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 5 Sep 2025 19:47:08 GMT Subject: RFR: 8364660: ClassVerifier::ends_in_athrow() should be removed [v2] In-Reply-To: References: <_eYRtNwm-zJ-7NvdPOffGv34zxCxfxbT_XmqN2c-F6k=.bfc23f40-079f-4cb6-a3c0-5ad50bc7d623@github.com> Message-ID: On Fri, 5 Sep 2025 16:00:05 GMT, Chen Liang wrote: > Do we need a test case emulating the scenario described by JVMS, to ensure the particular scenario once covered by ends_in_athrow is still covered? I think Oracle has enough test coverage in closed tests, but it wouldn't hurt to have more open tests. All I could find in a quick search was open/test/hotspot/jtreg/runtime/handlerInTry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27107#issuecomment-3259558199 From naoto at openjdk.org Fri Sep 5 20:20:15 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 20:20:15 GMT Subject: RFR: 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 17:06:32 GMT, Naoto Sato wrote: >> Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further requireNonNull() Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27060#issuecomment-3259643744 From naoto at openjdk.org Fri Sep 5 20:23:14 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 20:23:14 GMT Subject: Integrated: 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 19:29:37 GMT, Naoto Sato wrote: > Adding a `@throws` clause for NPE in `java.text.DateFormatSymbols(Locale)` constructor. The bug suggests it should throw a `MissingResourceException`, but I don't think we can change this long standing behavior. Instead, explicitly specify the NPE in the javadoc. This pull request has now been integrated. Changeset: 3824c7cd Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/3824c7cd06645b1dab5322015e8e6cf604afa754 Stats: 25 lines in 4 files changed: 20 ins; 0 del; 5 mod 8366517: Refine null locale processing of ctor/factory methods in `Date/DecimalFormatSymbols` Reviewed-by: jlu, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/27060 From pavel.rappo at gmail.com Fri Sep 5 20:31:41 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Fri, 5 Sep 2025 21:31:41 +0100 Subject: StableValue and non-deterministic iteration order In-Reply-To: <419F2BA6-CBBA-43E9-9DE4-73B41542CF68@iernst.net> References: <419F2BA6-CBBA-43E9-9DE4-73B41542CF68@iernst.net> Message-ID: We should be careful with words here. I think that in this thread people use "deterministic" casually as a synonym for "defined". "Defined" means not only repeatable but also specific. What's more, people seem to want to be able to specify it. So, arguably a better way would be to refer to such an order as **user-defined**. Back to Map.of. Even if a user could control the seed of the current implementation, the order would not be user-defined. It would be deterministic though. If the implementation of Map.of or the hash code of the objects a user stores there were to suddenly change, the order could change too. Be it Map.of or HashMap, there's no user-defined order. The only user-defined order one can currently get is by using LinkedHashMap. In the future though, we may get SequencedMap.of. On Fri, Sep 5, 2025 at 4:52?PM Ryan Ernst wrote: > > The iteration order is deterministic. The problem raised in that thread was that the seed is hidden and uncontrollable. > > IMO if you want a Map that has order, use a LinkedHashMap (or the idea is SequencedMap.of is also appealing). However, even if you don?t want to depend on iteration order, sometimes there are bugs that unintentionally depend on that order, so it would still be great to control the seed in order to have reproducibility in tests. > > On Sep 5, 2025, at 08:23, Kevin Bourrillion wrote: > > ? > > Just as a corroborating data point, it?s banned at my previous company too, and this is a big reason why. Deterministic iteration is a very good thing. (Personal opinion: I?ve come to view non-deterministic iteration as a risky optimization in general, that is usually not called for.) > > > > > > From: core-libs-dev on behalf of Stephen Colebourne > Date: Friday, September 5, 2025 at 12:13?AM > To: core-libs-dev > Subject: StableValue and non-deterministic iteration order > > > In summary, the current Map.of() is a bit of a hand grenade IMO, and > something I pretty much banned at my previous company. Which is a > problem given its key role in StableValue. > > Stephen From jlu at openjdk.org Fri Sep 5 20:32:20 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 20:32:20 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v2] In-Reply-To: References: Message-ID: <86E9-EBVDvyuyzNlx6U-_2MlDPUHmMEnQsjg9w9oXL8=.9ae4477a-4ae3-43aa-b16f-5d52dd001d29@github.com> > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Retain hex dump and test against older versions directly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27108/files - new: https://git.openjdk.org/jdk/pull/27108/files/95c3c0c7..59f07e9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=00-01 Stats: 383 lines in 7 files changed: 379 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27108.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27108/head:pull/27108 PR: https://git.openjdk.org/jdk/pull/27108 From jlu at openjdk.org Fri Sep 5 20:32:20 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 20:32:20 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Brought the hex dump files back (more appropriately under the DecimalFormat folder) and retained the original tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27108#issuecomment-3259669710 From serb at openjdk.org Fri Sep 5 20:43:09 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 5 Sep 2025 20:43:09 GMT Subject: RFR: 8361533: Apply java.io.Serial annotations in java.logging In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 02:58:28 GMT, Sergey Bylokhov wrote: > Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.logging module to enable stricter compile-time checking of serialization-related declarations. Only one class remains to be covered; all other relevant fields and methods are already annotated with `@Serial`. > > This annotation can be applied to these methods in the module: > > private void writeObject(java.io.ObjectOutputStream stream) throws IOException > private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > private void readObjectNoData() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > private static final ObjectStreamField[] serialPersistentFields > private static final long serialVersionUID > > > Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module. Looking for volunteers to review this trivial patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26208#issuecomment-3259693957 From rriggs at openjdk.org Fri Sep 5 20:48:10 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 5 Sep 2025 20:48:10 GMT Subject: RFR: 8361533: Apply java.io.Serial annotations in java.logging In-Reply-To: References: Message-ID: <140F6ftR7HAhDIvfDQfRwXZQccAOP7xpXNM4xXDAdDA=.35b362b2-970d-444a-928d-d948a961ce3e@github.com> On Wed, 9 Jul 2025 02:58:28 GMT, Sergey Bylokhov wrote: > Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.logging module to enable stricter compile-time checking of serialization-related declarations. Only one class remains to be covered; all other relevant fields and methods are already annotated with `@Serial`. > > This annotation can be applied to these methods in the module: > > private void writeObject(java.io.ObjectOutputStream stream) throws IOException > private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > private void readObjectNoData() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > private static final ObjectStreamField[] serialPersistentFields > private static final long serialVersionUID > > > Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module. Looks good; trivial. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26208#pullrequestreview-3190748044 From archie.cobbs at gmail.com Fri Sep 5 20:50:49 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Fri, 5 Sep 2025 15:50:49 -0500 Subject: StableValue and non-deterministic iteration order In-Reply-To: References: <419F2BA6-CBBA-43E9-9DE4-73B41542CF68@iernst.net> Message-ID: On Fri, Sep 5, 2025 at 3:32?PM Pavel Rappo wrote: > Be it Map.of or HashMap, there's no user-defined order. The only > user-defined order one can currently get is by using LinkedHashMap. In > the future though, we may get SequencedMap.of. I vote for adding SequencedMap.of(). That seems like a good solution to the problem at hand, as well as a generally useful addition. Of course if you believe that argument, then SequencedSet.of() would also be a good addition, since Set.of() also makes no ordering guarantees. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Fri Sep 5 21:11:21 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 21:11:21 GMT Subject: RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build [v2] In-Reply-To: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com> References: <5Md4ofOV67XKMqY82Vd8RRNFC4RV3_6bXHJZJJ1qCXU=.68601b24-f49d-41f8-9071-b84bc75bd863@github.com> Message-ID: <5-Zn_EAg4aWyL6DL9NzACsKHP_JtOxk-CbH4nA4BVN8=.6666d403-4d31-4cd4-92fd-87b055e792ce@github.com> On Tue, 2 Sep 2025 22:20:26 GMT, Chen Liang wrote: >> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class. >> >> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too. >> >> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData. >> >>
>> >> Diff from new to old (backwards): >> >> >> >> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> index 13ef65b..49408a2 100644 >> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java >> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java >> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer; >> import jdk.internal.vm.annotation.ForceInline; >> import jdk.internal.vm.annotation.Hidden; >> >> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator. >> -// Do not edit! >> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit. >> @AOTSafeClassInitializer >> final class VarHandleGuards { >> >> >> >>
>> >> Testing: java/lang/invoke. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Preexisting typos > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/build-vhguards > - Restore order > - 8366455: Move VarHandles.GuardMethodGenerator to execute on build Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27009#issuecomment-3259748920 From liach at openjdk.org Fri Sep 5 21:11:22 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 21:11:22 GMT Subject: Integrated: 8366455: Move VarHandles.GuardMethodGenerator to execute on build In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 19:13:27 GMT, Chen Liang wrote: > Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class. > > This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too. > > Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData. > >
> > Diff from new to old (backwards): > > > > liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > index 13ef65b..49408a2 100644 > --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java > +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java > @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer; > import jdk.internal.vm.annotation.ForceInline; > import jdk.internal.vm.annotation.Hidden; > > -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator. > -// Do not edit! > +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit. > @AOTSafeClassInitializer > final class VarHandleGuards { > > > >
> > Testing: java/lang/invoke. This pull request has now been integrated. Changeset: cdc8b5eb Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/cdc8b5eb83ed6335a65b93cfa0cf38932486c7e3 Stats: 2197 lines in 5 files changed: 340 ins; 1857 del; 0 mod 8366455: Move VarHandles.GuardMethodGenerator to execute on build Reviewed-by: psandoz, redestad, erikj ------------- PR: https://git.openjdk.org/jdk/pull/27009 From naoto at openjdk.org Fri Sep 5 21:14:17 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 21:14:17 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v2] In-Reply-To: <86E9-EBVDvyuyzNlx6U-_2MlDPUHmMEnQsjg9w9oXL8=.9ae4477a-4ae3-43aa-b16f-5d52dd001d29@github.com> References: <86E9-EBVDvyuyzNlx6U-_2MlDPUHmMEnQsjg9w9oXL8=.9ae4477a-4ae3-43aa-b16f-5d52dd001d29@github.com> Message-ID: <0CiO6X7STDojhN-y2aZSknIV66GexeGV_rMIradJ-mU=.8a6b2f51-987d-47ad-be33-1077cb56cab6@github.com> On Fri, 5 Sep 2025 20:32:20 GMT, Justin Lu wrote: >> This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. >> >> As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. >> >> These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. >> >> Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). >> >> **DFSDeserialization142.java & DFSSerialization142.java** (D) >> >> - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. >> >> **NumberFormat/DFSSerialization.java** (D) >> >> - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. >> - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. >> - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. >> >> **SerializationLoad.java & SerializationSave.java** (D) >> >> - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. >> >> **NumberRegression.java** (M) >> >> - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Retain hex dump and test against older versions directly LGTM. Thanks for revisiting the serialization tests. test/jdk/java/text/Format/DecimalFormat/DecimalFormat.114.txt line 2: > 1: # > 2: # Copyright (c) 1998, 2025, Oracle and/or its affiliates. All rights reserved. Nit: since the content of the file has not changed, I don't think we need to update the year ------------- PR Review: https://git.openjdk.org/jdk/pull/27108#pullrequestreview-3190796488 PR Review Comment: https://git.openjdk.org/jdk/pull/27108#discussion_r2326054684 From jlu at openjdk.org Fri Sep 5 21:39:36 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 21:39:36 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v3] In-Reply-To: References: Message-ID: <8sxIpUiYPlvs8yEyQFQcDARKjP_4C02j44N8mGNiMPY=.81c3c717-88d2-48ff-a59a-ee4b5f900220@github.com> > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Restore copyright years for hex dump files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27108/files - new: https://git.openjdk.org/jdk/pull/27108/files/59f07e9d..c57082c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27108&range=01-02 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27108.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27108/head:pull/27108 PR: https://git.openjdk.org/jdk/pull/27108 From jlu at openjdk.org Fri Sep 5 21:39:37 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 21:39:37 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v2] In-Reply-To: <0CiO6X7STDojhN-y2aZSknIV66GexeGV_rMIradJ-mU=.8a6b2f51-987d-47ad-be33-1077cb56cab6@github.com> References: <86E9-EBVDvyuyzNlx6U-_2MlDPUHmMEnQsjg9w9oXL8=.9ae4477a-4ae3-43aa-b16f-5d52dd001d29@github.com> <0CiO6X7STDojhN-y2aZSknIV66GexeGV_rMIradJ-mU=.8a6b2f51-987d-47ad-be33-1077cb56cab6@github.com> Message-ID: <-0NRA6CTbdNKNFKsmNAi64ySS_PtFBXyO0CPRyHbEtM=.cdeb1a6a-c268-46c7-ad50-a0afe99d64cd@github.com> On Fri, 5 Sep 2025 21:09:43 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Retain hex dump and test against older versions directly > > test/jdk/java/text/Format/DecimalFormat/DecimalFormat.114.txt line 2: > >> 1: # >> 2: # Copyright (c) 1998, 2025, Oracle and/or its affiliates. All rights reserved. > > Nit: since the content of the file has not changed, I don't think we need to update the year Restored in https://github.com/openjdk/jdk/pull/27108/commits/c57082c684961993b64b9627f4e64c5d7cea70b6 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27108#discussion_r2326093681 From erikj at openjdk.org Fri Sep 5 22:44:11 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 Sep 2025 22:44:11 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. make/modules/java.base/gensrc/GensrcBuffer.gmk line 162: > 160: $$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp > 161: $$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp > 162: $$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT) Indentation looks off here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326173444 From ihse at openjdk.org Fri Sep 5 22:50:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 5 Sep 2025 22:50:11 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 22:34:32 GMT, Erik Joelsson wrote: >> Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. > > make/modules/java.base/gensrc/GensrcBuffer.gmk line 162: > >> 160: $$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp >> 161: $$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp >> 162: $$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT) > > Indentation looks off here. I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326185455 From naoto at openjdk.org Fri Sep 5 23:08:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 23:08:41 GMT Subject: RFR: 8367021: Regression in LocaleDataTest refactoring Message-ID: A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/27130/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27130&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367021 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27130/head:pull/27130 PR: https://git.openjdk.org/jdk/pull/27130 From jlu at openjdk.org Fri Sep 5 23:19:10 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 5 Sep 2025 23:19:10 GMT Subject: RFR: 8367021: Regression in LocaleDataTest refactoring In-Reply-To: References: Message-ID: <9LSeqq53cdjE4uQBhl6Zw7rBvpa1xqMu_zJCv9hiAsM=.ba769751-d2a9-45e3-9991-ea22e6dbae4c@github.com> On Fri, 5 Sep 2025 23:03:08 GMT, Naoto Sato wrote: > A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27130#pullrequestreview-3191031657 From naoto at openjdk.org Fri Sep 5 23:30:10 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 5 Sep 2025 23:30:10 GMT Subject: RFR: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests [v3] In-Reply-To: <8sxIpUiYPlvs8yEyQFQcDARKjP_4C02j44N8mGNiMPY=.81c3c717-88d2-48ff-a59a-ee4b5f900220@github.com> References: <8sxIpUiYPlvs8yEyQFQcDARKjP_4C02j44N8mGNiMPY=.81c3c717-88d2-48ff-a59a-ee4b5f900220@github.com> Message-ID: On Fri, 5 Sep 2025 21:39:36 GMT, Justin Lu wrote: >> This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. >> >> As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. >> >> These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. >> >> Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). >> >> **DFSDeserialization142.java & DFSSerialization142.java** (D) >> >> - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. >> >> **NumberFormat/DFSSerialization.java** (D) >> >> - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. >> - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. >> - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. >> >> **SerializationLoad.java & SerializationSave.java** (D) >> >> - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. >> >> **NumberRegression.java** (M) >> >> - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Restore copyright years for hex dump files Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27108#pullrequestreview-3191048971 From joehw at openjdk.org Fri Sep 5 23:58:10 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 5 Sep 2025 23:58:10 GMT Subject: RFR: 8367021: Regression in LocaleDataTest refactoring In-Reply-To: References: Message-ID: <1-561kkcAj3rPXJC8GxxcL8CXD6UoPNLORVjN5Tu4jI=.b0c94f0b-df8a-4741-b0f3-bd6889df25aa@github.com> On Fri, 5 Sep 2025 23:03:08 GMT, Naoto Sato wrote: > A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27130#pullrequestreview-3191136843 From liach at openjdk.org Sat Sep 6 01:07:12 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Sep 2025 01:07:12 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> References: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> Message-ID: On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 #26749 was merged 4 days ago. Can we integrate this one now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3260152639 From weijun at openjdk.org Sat Sep 6 01:12:14 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 6 Sep 2025 01:12:14 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: <0ub8yevcVcLcmGSHH4edEdSjfrUwW5rAw140-Q4VuUM=.82ba246e-eae9-4b1b-a2d1-f43e8530da1b@github.com> References: <0ub8yevcVcLcmGSHH4edEdSjfrUwW5rAw140-Q4VuUM=.82ba246e-eae9-4b1b-a2d1-f43e8530da1b@github.com> Message-ID: On Thu, 4 Sep 2025 23:37:52 GMT, Naoto Sato wrote: >> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 133: >> >>> 131: Charset.forName(StaticProperty.stdinEncoding(), UTF_8.INSTANCE), >>> 132: Charset.forName(StaticProperty.stdoutEncoding(), UTF_8.INSTANCE))) : >>> 133: Optional.empty(); >> >> (Finally getting back to this.) >> >> The code returns an Optional containing a JdkConsoleImpl instance, or an empty Optional. However the comment above says it returns a JdkConsoleImpl instance or null. Which do we want it to be? Either is OK, but the comment should agree with the code. >> >> I think @wangweij might want to weigh in here since his code will be calling this. > > Ah, yes. Comment does not align with the code. I am fine either way too. Either is OK. `Optional` sounds more modern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2326325423 From serb at openjdk.org Sat Sep 6 03:32:29 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 6 Sep 2025 03:32:29 GMT Subject: RFR: 8361533: Apply java.io.Serial annotations in java.logging [v2] In-Reply-To: References: Message-ID: > Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.logging module to enable stricter compile-time checking of serialization-related declarations. Only one class remains to be covered; all other relevant fields and methods are already annotated with `@Serial`. > > This annotation can be applied to these methods in the module: > > private void writeObject(java.io.ObjectOutputStream stream) throws IOException > private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > private void readObjectNoData() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > private static final ObjectStreamField[] serialPersistentFields > private static final long serialVersionUID > > > Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8361533 - 8361533: Apply java.io.Serial annotations in java.logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26208/files - new: https://git.openjdk.org/jdk/pull/26208/files/9d4f1153..e6c35899 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26208&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26208&range=00-01 Stats: 115239 lines in 3014 files changed: 68646 ins; 30880 del; 15713 mod Patch: https://git.openjdk.org/jdk/pull/26208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26208/head:pull/26208 PR: https://git.openjdk.org/jdk/pull/26208 From alanb at openjdk.org Sat Sep 6 07:04:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 6 Sep 2025 07:04:14 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: References: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> Message-ID: On Sat, 6 Sep 2025 01:04:56 GMT, Chen Liang wrote: > #26749 was merged 4 days ago. Can we integrate this one now? I think it would be useful to get input from @dholmes-ora and @lkorinth before doing this. There seems to be several timeout issues in the last few days, a few follow-on changes to adjust the timeout of a few tests, and a spate of tests being reported as timed out after passing. Updating jtreg adds another change to the picture. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3261436239 From duke at openjdk.org Sat Sep 6 08:24:09 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Sat, 6 Sep 2025 08:24:09 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 09:00:32 GMT, Francesco Andreuzzi wrote: > In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. > > Passes tests in `jdk/classfile`. Hi @liach, could you have a look at this PR since you opened the ticket? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27029#issuecomment-3261581258 From ihse at openjdk.org Sat Sep 6 09:05:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sat, 6 Sep 2025 09:05:10 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 22:47:58 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/gensrc/GensrcBuffer.gmk line 162: >> >>> 160: $$(CAT) $$($1_BIN_SNIPPET_FILES) >> $$($1_REAL_OUTPUT).tmp >>> 161: $$(ECHO) "}" >> $$($1_REAL_OUTPUT).tmp >>> 162: $$(MV) $$($1_REAL_OUTPUT).tmp $$($1_REAL_OUTPUT) >> >> Indentation looks off here. > > I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect. Turns out you can actually change the tab size setting on GitHub. They set 4 as default but you can change it to 8 at https://github.com/settings/appearance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2326684556 From liach at openjdk.org Sat Sep 6 13:37:13 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Sep 2025 13:37:13 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 09:00:32 GMT, Francesco Andreuzzi wrote: > In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. > > Passes tests in `jdk/classfile`. Thanks for pinging me. This must have got forgotten in the stream of emails. src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 145: > 143: } > 144: } else if (fr.stack().size() == 1 && fr.locals().equals(prevLocals)) { > 145: if (offsetDelta <= SAME_FRAME_END) { //same locals 1 stack item frame This is better represented as Suggestion: if (offsetDelta <= SAME_LOCALS_1_STACK_ITEM_FRAME_END - SAME_LOCALS_1_STACK_ITEM_FRAME_START) { //same locals 1 stack item frame src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 188: > 186: > 187: public static final int > 188: SAME_FRAME_END = 63, Can you add a comment on these constants that they are inclusive on both ends? A lot of ranges in Java are open on their higher end, like range notations in Arrays.copyOf or String.substring. src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1256: > 1254: } > 1255: } else if (stackSize == 1 && localsSize == prevFrame.localsSize && equals(locals, prevFrame.locals, localsSize)) { > 1256: if (offsetDelta <= SAME_FRAME_END) { //same locals 1 stack item frame Suggestion: if (offsetDelta <= SAME_LOCALS_1_STACK_ITEM_FRAME_END - SAME_LOCALS_1_STACK_ITEM_FRAME_START) { //same locals 1 stack item frame Same comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27029#issuecomment-3262178996 PR Review Comment: https://git.openjdk.org/jdk/pull/27029#discussion_r2327393978 PR Review Comment: https://git.openjdk.org/jdk/pull/27029#discussion_r2327385656 PR Review Comment: https://git.openjdk.org/jdk/pull/27029#discussion_r2327398615 From duke at openjdk.org Sat Sep 6 13:45:01 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Sat, 6 Sep 2025 13:45:01 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v2] In-Reply-To: References: Message-ID: > In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. > > Passes tests in `jdk/classfile`. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27029/files - new: https://git.openjdk.org/jdk/pull/27029/files/0ca1e717..4a9bf431 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27029&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27029&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27029.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27029/head:pull/27029 PR: https://git.openjdk.org/jdk/pull/27029 From duke at openjdk.org Sat Sep 6 13:48:53 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Sat, 6 Sep 2025 13:48:53 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v3] In-Reply-To: References: Message-ID: > In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. > > Passes tests in `jdk/classfile`. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: inclusive ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27029/files - new: https://git.openjdk.org/jdk/pull/27029/files/4a9bf431..0c6c04b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27029&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27029&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27029.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27029/head:pull/27029 PR: https://git.openjdk.org/jdk/pull/27029 From duke at openjdk.org Sat Sep 6 13:48:54 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Sat, 6 Sep 2025 13:48:54 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v3] In-Reply-To: References: Message-ID: On Sat, 6 Sep 2025 13:22:56 GMT, Chen Liang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> inclusive > > src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 188: > >> 186: >> 187: public static final int >> 188: SAME_FRAME_END = 63, > > Can you add a comment on these constants that they are inclusive on both ends? A lot of ranges in Java are open on their higher end, like range notations in Arrays.copyOf or String.substring. Sure: 0c6c04b7b8874d3b3bd53c4f9456fe01b151241d ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27029#discussion_r2327436560 From liach at openjdk.org Sat Sep 6 13:58:10 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Sep 2025 13:58:10 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v3] In-Reply-To: References: Message-ID: <3oy8Hi7bJ9AcFng3DllV3FUfaZHh5czBkeMKHzLI0l4=.cc81efe4-8504-401a-b7f6-7bb02ad4b4ea@github.com> On Sat, 6 Sep 2025 13:48:53 GMT, Francesco Andreuzzi wrote: >> In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. >> >> Passes tests in `jdk/classfile`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > inclusive Reviewer's note: This brings more parity with c++ verifier code as done in JDK-8359920 (28e96e333b61dfe60a84a48ff59bdf10c529f8be) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27029#issuecomment-3262216411 From duke at openjdk.org Sat Sep 6 14:06:15 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Sat, 6 Sep 2025 14:06:15 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v3] In-Reply-To: <3oy8Hi7bJ9AcFng3DllV3FUfaZHh5czBkeMKHzLI0l4=.cc81efe4-8504-401a-b7f6-7bb02ad4b4ea@github.com> References: <3oy8Hi7bJ9AcFng3DllV3FUfaZHh5czBkeMKHzLI0l4=.cc81efe4-8504-401a-b7f6-7bb02ad4b4ea@github.com> Message-ID: On Sat, 6 Sep 2025 13:55:03 GMT, Chen Liang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> inclusive > > Reviewer's note: This brings more parity with c++ verifier code as done in JDK-8359920 (28e96e333b61dfe60a84a48ff59bdf10c529f8be) Thanks for the review @liach ------------- PR Comment: https://git.openjdk.org/jdk/pull/27029#issuecomment-3262230970 From liach at openjdk.org Sat Sep 6 14:18:10 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Sep 2025 14:18:10 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v3] In-Reply-To: References: Message-ID: On Sat, 6 Sep 2025 13:48:53 GMT, Francesco Andreuzzi wrote: >> In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. >> >> Passes tests in `jdk/classfile`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > inclusive Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27029#pullrequestreview-3192855414 From duke at openjdk.org Sat Sep 6 14:46:11 2025 From: duke at openjdk.org (duke) Date: Sat, 6 Sep 2025 14:46:11 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v3] In-Reply-To: References: Message-ID: On Sat, 6 Sep 2025 13:48:53 GMT, Francesco Andreuzzi wrote: >> In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. >> >> Passes tests in `jdk/classfile`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > inclusive @fandreuz Your change (at version 0c6c04b7b8874d3b3bd53c4f9456fe01b151241d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27029#issuecomment-3262317395 From liach at openjdk.org Sat Sep 6 15:03:10 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Sep 2025 15:03:10 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v3] In-Reply-To: References: Message-ID: On Sat, 6 Sep 2025 13:48:53 GMT, Francesco Andreuzzi wrote: >> In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. >> >> Passes tests in `jdk/classfile`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > inclusive I will wait for the CI results before integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27029#issuecomment-3262353565 From dl at openjdk.org Sat Sep 6 16:13:28 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 6 Sep 2025 16:13:28 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v6] In-Reply-To: References: Message-ID: <10ahCd72lyhKwYOzsX1RuGP4pFjfce9zF45C3cdvJpo=.6ea0b880-fe1a-4f68-9cff-58942ff83e14@github.com> > This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Refactor to improve locality and signalling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26479/files - new: https://git.openjdk.org/jdk/pull/26479/files/8ecf3987..54220a19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=04-05 Stats: 325 lines in 1 file changed: 64 ins; 136 del; 125 mod Patch: https://git.openjdk.org/jdk/pull/26479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479 PR: https://git.openjdk.org/jdk/pull/26479 From dl at openjdk.org Sat Sep 6 20:10:39 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 6 Sep 2025 20:10:39 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v7] In-Reply-To: References: Message-ID: > This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8360046 - Refactor to improve locality and signalling - Avoid underutilization on resize - Merge branch 'openjdk:master' into JDK-8360046 - Undo inadvertent acquire change - Add adapt(callable) case to test - Whitespace - Merge branch 'openjdk:master' into JDK-8360046 - Avoid unnecessary use of InterruptibleTask; misc cleanup - revert runWorker; tweak external probes - ... and 4 more: https://git.openjdk.org/jdk/compare/1ec5c22e...51950550 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26479/files - new: https://git.openjdk.org/jdk/pull/26479/files/54220a19..51950550 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=05-06 Stats: 74512 lines in 2216 files changed: 45912 ins; 19576 del; 9024 mod Patch: https://git.openjdk.org/jdk/pull/26479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479 PR: https://git.openjdk.org/jdk/pull/26479 From duke at openjdk.org Sat Sep 6 20:50:20 2025 From: duke at openjdk.org (Saint Wesonga) Date: Sat, 6 Sep 2025 20:50:20 GMT Subject: RFR: 8367027: java/lang/ProcessBuilder/Basic.java fails on Windows AArch64 Message-ID: This test fails with errors like >'=C:=,=ExitValue=3,PROCESSOR_ARCHITECTURE=ARM64,SystemRoot=C:\Windows,'< not equal to '=C:=,=ExitValue=3,SystemRoot=C:\Windows,' The test does not expect the PROCESSOR_ARCHITECTURE variable to be returned from the ProcessBuilder (called at https://github.com/openjdk/jdk/blob/431f46724658b703e995e518cb7a2149c50d6a9d/test/jdk/java/lang/ProcessBuilder/Basic.java#L127 for example). The fix is to treat it as an expected variable and strip it out from the results, similar to how macOS and AIX strip out their expected variables. The winEnvFilter method needs to be updated because some checks like https://github.com/openjdk/jdk/blob/431f46724658b703e995e518cb7a2149c50d6a9d/test/jdk/java/lang/ProcessBuilder/Basic.java#L1694 have the output on separate lines as opposed to the inline comma-separated format where removeWindowsAArch64ExpectedVars is used. ------------- Commit messages: - java/lang/ProcessBuilder/Basic.java fails on Windows AArch64 Changes: https://git.openjdk.org/jdk/pull/27131/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27131&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367027 Stats: 23 lines in 1 file changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27131.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27131/head:pull/27131 PR: https://git.openjdk.org/jdk/pull/27131 From ghan at openjdk.org Sun Sep 7 09:03:56 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Sun, 7 Sep 2025 09:03:56 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v14] In-Reply-To: References: Message-ID: <7rQDyDaw1GZM_SbrURgfHLATN62eLtRjlioY1jtaLF8=.5cc2ee76-253d-41e0-ba76-76582f1581cb@github.com> > Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: - Optimize implementation - Merge remote-tracking branch 'upstream/master' into 8328874 - move common method into a common file. - Merge remote-tracking branch 'upstream/master' into 8328874 - Update Class.java change overflow check - Update Class.java Simplify length check - Update Class.java avoid the case of int overflow - Update Class.java Use ModifiedUtf.utfLen instead of static import for readability - change copyright year - a small fix - ... and 8 more: https://git.openjdk.org/jdk/compare/0c155b4f...c01a6d58 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26802/files - new: https://git.openjdk.org/jdk/pull/26802/files/edc1694d..c01a6d58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=12-13 Stats: 7116 lines in 177 files changed: 3643 ins; 2526 del; 947 mod Patch: https://git.openjdk.org/jdk/pull/26802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802 PR: https://git.openjdk.org/jdk/pull/26802 From duke at openjdk.org Sun Sep 7 09:44:12 2025 From: duke at openjdk.org (ExE Boss) Date: Sun, 7 Sep 2025 09:44:12 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v14] In-Reply-To: <7rQDyDaw1GZM_SbrURgfHLATN62eLtRjlioY1jtaLF8=.5cc2ee76-253d-41e0-ba76-76582f1581cb@github.com> References: <7rQDyDaw1GZM_SbrURgfHLATN62eLtRjlioY1jtaLF8=.5cc2ee76-253d-41e0-ba76-76582f1581cb@github.com> Message-ID: On Sun, 7 Sep 2025 09:03:56 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: > > - Optimize implementation > - Merge remote-tracking branch 'upstream/master' into 8328874 > - move common method into a common file. > - Merge remote-tracking branch 'upstream/master' into 8328874 > - Update Class.java > > change overflow check > - Update Class.java > > Simplify length check > - Update Class.java > > avoid the case of int overflow > - Update Class.java > > Use ModifiedUtf.utfLen instead of static import for readability > - change copyright year > - a small fix > - ... and 8 more: https://git.openjdk.org/jdk/compare/57721ee7...c01a6d58 src/java.base/share/classes/jdk/internal/util/ModifiedUtf.java line 95: > 93: // The check utfLen >= strLen ensures we don't incorrectly return true in case of int overflow. > 94: int utfLen = utfLen(str, 0); > 95: return utfLen >= strLen && utfLen <= CONSTANT_POOL_UTF8_MAX_BYTES; Now?that the?`strLen >?CONSTANT_POOL_UTF8_MAX_BYTES` check?is?performed?above, `utfLen` can?be?at?most `CONSTANT_POOL_UTF8_MAX_BYTES *?3`?here (`196_605`), which?can?t overflow?an?`int`, so?this?check can?be?simplified: Suggestion: // The check strLen > CONSTANT_POOL_UTF8_MAX_BYTES above ensures that utfLen can't overflow here. int utfLen = utfLen(str, 0); return utfLen <= CONSTANT_POOL_UTF8_MAX_BYTES; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2328596638 From ghan at openjdk.org Sun Sep 7 14:50:56 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Sun, 7 Sep 2025 14:50:56 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v15] In-Reply-To: References: Message-ID: > Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Use a different native method for testNative, since the implementation of forName has changed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26802/files - new: https://git.openjdk.org/jdk/pull/26802/files/c01a6d58..2ca6354a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=13-14 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802 PR: https://git.openjdk.org/jdk/pull/26802 From dl at openjdk.org Sun Sep 7 18:28:54 2025 From: dl at openjdk.org (Doug Lea) Date: Sun, 7 Sep 2025 18:28:54 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v8] In-Reply-To: References: Message-ID: > This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. Doug Lea has updated the pull request incrementally with one additional commit since the last revision: revive topLevelExec, adjust occrdingly; small teaks and copy-edits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26479/files - new: https://git.openjdk.org/jdk/pull/26479/files/51950550..31d2f486 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=06-07 Stats: 79 lines in 1 file changed: 21 ins; 14 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/26479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479 PR: https://git.openjdk.org/jdk/pull/26479 From serb at openjdk.org Sun Sep 7 23:21:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 7 Sep 2025 23:21:15 GMT Subject: Integrated: 8361533: Apply java.io.Serial annotations in java.logging In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 02:58:28 GMT, Sergey Bylokhov wrote: > Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.logging module to enable stricter compile-time checking of serialization-related declarations. Only one class remains to be covered; all other relevant fields and methods are already annotated with `@Serial`. > > This annotation can be applied to these methods in the module: > > private void writeObject(java.io.ObjectOutputStream stream) throws IOException > private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException > private void readObjectNoData() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException > ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException > private static final ObjectStreamField[] serialPersistentFields > private static final long serialVersionUID > > > Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module. This pull request has now been integrated. Changeset: 14a40fd5 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/14a40fd579b087f061da086f5eb18230c379dce0 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8361533: Apply java.io.Serial annotations in java.logging Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/26208 From liach at openjdk.org Sun Sep 7 23:23:19 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 7 Sep 2025 23:23:19 GMT Subject: RFR: 8354871: Replace stack map frame type magics with constants [v3] In-Reply-To: References: Message-ID: On Sat, 6 Sep 2025 13:48:53 GMT, Francesco Andreuzzi wrote: >> In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. >> >> Passes tests in `jdk/classfile`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > inclusive Tier 1-3 looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27029#issuecomment-3264142681 From duke at openjdk.org Sun Sep 7 23:23:20 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Sun, 7 Sep 2025 23:23:20 GMT Subject: Integrated: 8354871: Replace stack map frame type magics with constants In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 09:00:32 GMT, Francesco Andreuzzi wrote: > In this PR I introduce some constants in `StackMapGenerator`. No change in logic is expected. > > Passes tests in `jdk/classfile`. This pull request has now been integrated. Changeset: 8a6b8751 Author: Francesco Andreuzzi Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/8a6b8751e1a8ad93646bf3900186802c863d7119 Stats: 125 lines in 7 files changed: 22 ins; 26 del; 77 mod 8354871: Replace stack map frame type magics with constants Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/27029 From ghan at openjdk.org Sun Sep 7 23:48:11 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Sun, 7 Sep 2025 23:48:11 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v12] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 18:40:26 GMT, Roger Riggs wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Class.java >> >> change overflow check > >> /reviewers 2 reviewer >> >> I recommend putting this PR on hold - 65535 encoded size for modified utf8 is significant enough for a cross-JDK utility. As @rose00 suggested, I think I will explore adding a check in ClassFile API, and sharing the check with here. > > A common boolean function is useful and can be better optimized. > The function should be in a common utility area, but the ClassFile API is a higher level API specific to class files. > Most developers won't think to look there. The jdk.internal.util.ModifiedUtf isn't a bad place for both the boolean function and the utfLen function. @RogerRiggs @liach I?ve addressed the feedback in this PR. Please review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3264157849 From duke at openjdk.org Mon Sep 8 01:25:18 2025 From: duke at openjdk.org (erifan) Date: Mon, 8 Sep 2025 01:25:18 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 10:12:35 GMT, Aleksey Shipilev wrote: >> Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 >> microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 >> microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 >> microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 >> microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 >> microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 >> microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 >> microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 >> microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 >> microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 >> >> >> Benchmarks on Intel 6444y machine with 512-bit avx3: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 >> microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 >> microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 >> microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 >> microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 >> microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 >> microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 >> microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 >> microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 >> microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 >> microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 >> microMaskLaneIsSetInt512_var ops/ms 573... > > test/micro/org/openjdk/bench/jdk/incubator/vector/VectorExtractBenchmark.java line 34: > >> 32: @Warmup(iterations = 5, time = 1) >> 33: @Measurement(iterations = 5, time = 1) >> 34: @Fork(value = 1, jvmArgs = {"--add-modules=jdk.incubator.vector"}) > > Don't do 1 fork, do at least 3. The test results show that this test is stable, so I think forking once is enough? We have many JMH benchmarks that fork once. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27113#discussion_r2328949227 From swen at openjdk.org Mon Sep 8 02:27:10 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 8 Sep 2025 02:27:10 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> > This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. > > Changes include: > > 1. New `appendPair` method for efficient two-digit integer formatting (00-99): > - Added `AbstractStringBuilder.appendPair(int i)` with core implementation > - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access > - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge > - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method > - Enhanced Javadoc documentation for all new methods > > 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: > - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` > - Replaced manual formatting logic with the new efficient two-digit appending > - Improved code clarity and consistency in date/time formatting > > These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge remote-tracking branch 'upstream/master' into appendPair_202508 # Conflicts: # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding - Use DecimalDigits.appendPair for formatting in time classes This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. Co-authored-by: Qwen-Coder - Optimize year formatting in DateTimeHelper by reducing modulo operation Co-authored-by: Qwen-Coder Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. Co-authored-by: Qwen-Coder - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. Co-authored-by: Qwen-Coder ------------- Changes: https://git.openjdk.org/jdk/pull/26911/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=03 Stats: 199 lines in 10 files changed: 168 ins; 4 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/26911.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911 PR: https://git.openjdk.org/jdk/pull/26911 From dholmes at openjdk.org Mon Sep 8 04:27:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Sep 2025 04:27:19 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> References: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> Message-ID: On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 I would appreciate it if this could hold off a while longer as we have a few issues causing noise in our testing at the moment and I don't want to muddy the waters even further. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3264544890 From alanb at openjdk.org Mon Sep 8 06:39:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Sep 2025 06:39:14 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs [v4] In-Reply-To: References: <-sJZGmlwKVOGrdCEe4Wqx5Hvig4q3ow1RKDa1n8uhKA=.bb2fb3c5-53ed-44bc-b268-8ac01327aee5@github.com> Message-ID: On Wed, 3 Sep 2025 12:08:49 GMT, Darragh Clarke wrote: > So I double checked the changes made there and wrote this up, I can make it more precise or change wording if its going to be attached to a file. Package info currently contains the script used to generate the code > > **Common changes:** > > * utility methods and constant values got moved into FFMUtils, this is to cut down on duplicated code as more FFM code gets added > * kqueue_h and kevent both get updated to reference FFMUtils > * `@SuppressWarnings("restricted")` is added above the class declarations > > **kqueue_h specific changes:** > > * Errno handling had to be added, this involved adding the `ADAPTED` method handles as well as editing the `HANDLE` methodhandle to add `Linker.Option.captureCallState(ERRNO_NAME));` > * Removing some unused generated objects such as `static final Arena LIBRARY_ARENA = Arena.ofAuto();` > * added `private static final String ERRNO_NAME = "errno?;` It might also help if the integration were split into two. A first commit with the jextract-generated files, then a second that has the changes. That would capture in the git log the changes that were made, and would also make things much easier to review too as it would be obvious what has been changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3264814812 From tvaleev at openjdk.org Mon Sep 8 07:05:17 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Mon, 8 Sep 2025 07:05:17 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v7] In-Reply-To: References: Message-ID: On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev wrote: >> 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. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Add @implSpec (still waiting for CSR review) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-3264886241 From per-ake.minborg at oracle.com Mon Sep 8 07:34:44 2025 From: per-ake.minborg at oracle.com (Per-Ake Minborg) Date: Mon, 8 Sep 2025 07:34:44 +0000 Subject: StableValue and non-deterministic iteration order In-Reply-To: References: <419F2BA6-CBBA-43E9-9DE4-73B41542CF68@iernst.net> Message-ID: Stable Map Background The iteration order of `StableValue.map()` is not specified, and the returned map is not an instance of SequencedMap. The current implementation happens to rely on Map.of() for which the iteration order of mappings is specified to be unspecified and subject to change (i.e., indeterministic). This was a deliberate design choice. Hence, StableValue.map() currently has the same iteration order properties as Map.of(). The Way Forward for Stable Map There are several alternatives for the future, all of which have different pros and cons, including but not limited to, and in no particular order (pun not intended): * The iteration order remains unspecified as today (and could be fixed/random/always having 42 at the front/...), * We specify that the order is unspecified and subject to change (like Map.of()), * We specify that the order is unspecified but will always remain the same (i.e., not subject to change/is deterministic), * We specify that the order is specified and coincides with the iteration order of the given Set at construction time, or * We allow the client to provide a Comparator that decides the iteration order I think there is a more general discussion to be had that should be aligned with the direction of the immutable collections and any potential constructs with deterministic order there. Best, Per ________________________________ From: core-libs-dev on behalf of Archie Cobbs Sent: Friday, September 5, 2025 10:50 PM To: Pavel Rappo Cc: Ryan Ernst ; Kevin Bourrillion ; Stephen Colebourne ; core-libs-dev Subject: Re: StableValue and non-deterministic iteration order On Fri, Sep 5, 2025 at 3:32?PM Pavel Rappo > wrote: Be it Map.of or HashMap, there's no user-defined order. The only user-defined order one can currently get is by using LinkedHashMap. In the future though, we may get SequencedMap.of. I vote for adding SequencedMap.of(). That seems like a good solution to the problem at hand, as well as a generally useful addition. Of course if you believe that argument, then SequencedSet.of() would also be a good addition, since Set.of() also makes no ordering guarantees. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From scolebourne at joda.org Mon Sep 8 07:58:53 2025 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 8 Sep 2025 08:58:53 +0100 Subject: StableValue and non-deterministic iteration order In-Reply-To: References: <419F2BA6-CBBA-43E9-9DE4-73B41542CF68@iernst.net> Message-ID: On Mon, 8 Sept 2025 at 08:34, Per-Ake Minborg wrote: > I think there is a more general discussion to be had that should be aligned with the direction of the immutable collections and any potential constructs with deterministic order there. I agree, because the direction of travel for Map.of() influences StableValue: ie. I don't think StableValue should be released until this thread/issue is decided. * If the decision is to add SequencedMap.of() and SequencedSet.of(), then it would make sense for StableValue.map() to return SequencedMap, not Map. * However, if the decision is to alter Map.of() and Set.of() and friends to retain their input order, then StableValue.map() is fine returning a Map. (Personally, I would prefer to see Map.of() and friends retain their input order, as I think that is by far what most developers expect, and I think the performance overhead is hugely overblown as an issue.) thanks Stephen From shade at openjdk.org Mon Sep 8 08:10:10 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 8 Sep 2025 08:10:10 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 01:22:46 GMT, erifan wrote: >> test/micro/org/openjdk/bench/jdk/incubator/vector/VectorExtractBenchmark.java line 34: >> >>> 32: @Warmup(iterations = 5, time = 1) >>> 33: @Measurement(iterations = 5, time = 1) >>> 34: @Fork(value = 1, jvmArgs = {"--add-modules=jdk.incubator.vector"}) >> >> Don't do 1 fork, do at least 3. > > The test results show that this test is stable, so I think forking once is enough? We have many JMH benchmarks that fork once. OK then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27113#discussion_r2329468832 From tschatzl at openjdk.org Mon Sep 8 09:09:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Sep 2025 09:09:49 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * sort includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/2a614a2c..4601bf88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=52-53 Stats: 7 lines in 4 files changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Mon Sep 8 09:50:19 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Sep 2025 09:50:19 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3265474466 From erikj at openjdk.org Mon Sep 8 13:20:19 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Sep 2025 13:20:19 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27078#pullrequestreview-3196501441 From erikj at openjdk.org Mon Sep 8 13:20:21 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Sep 2025 13:20:21 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Sat, 6 Sep 2025 09:02:59 GMT, Magnus Ihse Bursie wrote: >> I think it is per our standard. It seems the Github diff viewer expands tabs to 4 spaces, which makes it looks incorrect. > > Turns out you can actually change the tab size setting on GitHub. They set 4 as default but you can change it to 8 at https://github.com/settings/appearance. You are right, thanks for that link! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27078#discussion_r2330222469 From jwaters at openjdk.org Mon Sep 8 14:25:02 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:25:02 GMT Subject: RFR: 8342869: Errors related to unused code on Windows after 8339120 in awt [v2] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > build.log on release configuration: > > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=] > 3560 | static const UINT _VKS_ALT_MASK = 0x04; > | ^~~~~~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs] > 1361 | } SUBTABLE, *PSUBTABLE; > | ^~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs] > 1588 | } HEAD, *PHEAD; > | ^~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs] > 1595 | } ENTRY, *PENTRY; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/... Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into awt - 8342869 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21655/files - new: https://git.openjdk.org/jdk/pull/21655/files/ee4d1bb5..90903171 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21655&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21655&range=00-01 Stats: 1560860 lines in 20249 files changed: 770956 ins; 654744 del; 135160 mod Patch: https://git.openjdk.org/jdk/pull/21655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21655/head:pull/21655 PR: https://git.openjdk.org/jdk/pull/21655 From jwaters at openjdk.org Mon Sep 8 14:28:27 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:28:27 GMT Subject: RFR: 8342869: Errors related to unused code on Windows after 8339120 in awt [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 14:25:02 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=] >> 3560 | static const UINT _VKS_ALT_MASK = 0x04; >> | ^~~~~~~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs] >> 1361 | } SUBTABLE, *PSUBTABLE; >> | ^~~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs] >> 1588 | } HEAD, *PHEAD; >> | ^~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs] >> 1595 | } ENTRY, *PENTRY; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/w... > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into awt > - 8342869 Hi Phil, would it help if I split out the moving of DrawingStateProp to the C++ file to another Pull Request? Majority of this Pull Request is dead constants and the remainder are things that are needed but will raise an unused error anyway (Like the struct typedefs) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-3266585629 From duke at openjdk.org Mon Sep 8 14:34:06 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 8 Sep 2025 14:34:06 GMT Subject: RFR: 8077587: BigInteger Roots [v82] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Revision changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/51194db3..1afb095a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=81 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=80-81 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From rgiulietti at openjdk.org Mon Sep 8 15:01:28 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 8 Sep 2025 15:01:28 GMT Subject: RFR: 8077587: BigInteger Roots [v82] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 14:34:06 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Revision changes @jddarcy @fabioromano1 It seems that `MutableBigInteger.valueOf()` is not used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3266723998 From duke at openjdk.org Mon Sep 8 15:05:25 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 8 Sep 2025 15:05:25 GMT Subject: RFR: 8077587: BigInteger Roots [v82] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 14:58:19 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Revision changes > > @jddarcy @fabioromano1 It seems that `MutableBigInteger.valueOf()` is not used. @rgiulietti So it's time to remove `MutableBigInteger.valueOf()` or is it better to leave it because it could be useful for casting `double` values into `MutableBigInteger`s? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3266747155 From rgiulietti at openjdk.org Mon Sep 8 15:11:23 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 8 Sep 2025 15:11:23 GMT Subject: RFR: 8077587: BigInteger Roots [v82] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 14:34:06 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Revision changes Personally I tend to remove code that is not used. I can't recall why it was added: there might have been reasons that do no longer seem to be relevant. It should be straightforward to add it once need arises. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3266768567 From duke at openjdk.org Mon Sep 8 15:16:20 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 8 Sep 2025 15:16:20 GMT Subject: RFR: 8077587: BigInteger Roots [v82] In-Reply-To: References: Message-ID: <73TK4BDwK0oE4OFNw7WUBct6WGH5SQqJWbRiqWIxZcw=.36ce8381-a77b-4ef7-b1f6-20fb8c89901c@github.com> On Mon, 8 Sep 2025 15:08:24 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Revision changes > > Personally I tend to remove code that is not used. > I can't recall why it was added: there might have been reasons that do no longer seem to be relevant. > It should be straightforward to add it once need arises. @rgiulietti The reason was that the `double` approximation of the root couldn't be casted directly into an `int` before taking into account to shift out the wrong bits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3266789071 From rgiulietti at openjdk.org Mon Sep 8 15:39:22 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 8 Sep 2025 15:39:22 GMT Subject: RFR: 8077587: BigInteger Roots [v82] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 14:34:06 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Revision changes If you need this method for the `BigDecimal.nthRoot()` work, then add it in that PR. But for this PR I suggest removing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3266878578 From duke at openjdk.org Mon Sep 8 15:45:07 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 8 Sep 2025 15:45:07 GMT Subject: RFR: 8077587: BigInteger Roots [v83] In-Reply-To: References: Message-ID: > This PR implements nth root computation for BigIntegers using Newton method. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Removed MBI.valueOf(double) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24898/files - new: https://git.openjdk.org/jdk/pull/24898/files/1afb095a..c9950b61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=82 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24898&range=81-82 Stats: 21 lines in 1 file changed: 0 ins; 21 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24898/head:pull/24898 PR: https://git.openjdk.org/jdk/pull/24898 From rgiulietti at openjdk.org Mon Sep 8 15:55:23 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 8 Sep 2025 15:55:23 GMT Subject: RFR: 8077587: BigInteger Roots [v83] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 15:45:07 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Removed MBI.valueOf(double) Thanks for your efforts. Now looking forward to `BigDecimal.nthRoot()` ;-) ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24898#pullrequestreview-3197143179 From duke at openjdk.org Mon Sep 8 16:01:30 2025 From: duke at openjdk.org (duke) Date: Mon, 8 Sep 2025 16:01:30 GMT Subject: RFR: 8077587: BigInteger Roots [v83] In-Reply-To: References: Message-ID: <0y-qhU-IRLRIRDaIGB9HVY45YVQK_0I5mDjvAvEzCWY=.d801d0f3-2e05-41d7-8f7c-62ad1de9abd1@github.com> On Mon, 8 Sep 2025 15:45:07 GMT, fabioromano1 wrote: >> This PR implements nth root computation for BigIntegers using Newton method. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Removed MBI.valueOf(double) @fabioromano1 Your change (at version c9950b6156e61f6bc87e9e1f89238a73ef29a53f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3266968619 From duke at openjdk.org Mon Sep 8 16:13:36 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 8 Sep 2025 16:13:36 GMT Subject: Integrated: 8077587: BigInteger Roots In-Reply-To: References: Message-ID: On Sat, 26 Apr 2025 16:15:29 GMT, fabioromano1 wrote: > This PR implements nth root computation for BigIntegers using Newton method. This pull request has now been integrated. Changeset: ab12fbfd Author: Fabio Romano Committer: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/ab12fbfda2c364bb16ddf03b923989639f437f6a Stats: 433 lines in 3 files changed: 430 ins; 0 del; 3 mod 8077587: BigInteger Roots Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/24898 From naoto at openjdk.org Mon Sep 8 16:26:16 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Sep 2025 16:26:16 GMT Subject: RFR: 8367021: Regression in LocaleDataTest refactoring In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 23:03:08 GMT, Naoto Sato wrote: > A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27130#issuecomment-3267052349 From naoto at openjdk.org Mon Sep 8 16:26:17 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Sep 2025 16:26:17 GMT Subject: Integrated: 8367021: Regression in LocaleDataTest refactoring In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 23:03:08 GMT, Naoto Sato wrote: > A small fix to a locale test regression. Auto flush was incorrectly set to default (= false) by the prior fix. This pull request has now been integrated. Changeset: 48831c65 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/48831c65b5535fef706b64a4eb23ba28b1567ead Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8367021: Regression in LocaleDataTest refactoring Reviewed-by: jlu, joehw ------------- PR: https://git.openjdk.org/jdk/pull/27130 From naoto at openjdk.org Mon Sep 8 16:34:29 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Sep 2025 16:34:29 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v6] In-Reply-To: References: Message-ID: > Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26973/files - new: https://git.openjdk.org/jdk/pull/26973/files/ff7e9e0d..9306bc0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26973/head:pull/26973 PR: https://git.openjdk.org/jdk/pull/26973 From naoto at openjdk.org Mon Sep 8 16:34:29 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Sep 2025 16:34:29 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v5] In-Reply-To: References: <0ub8yevcVcLcmGSHH4edEdSjfrUwW5rAw140-Q4VuUM=.82ba246e-eae9-4b1b-a2d1-f43e8530da1b@github.com> Message-ID: <30fJ-qVeGVgkAj05nx8d5zyCYQ5esO3-i69q-Avym-M=.739bf041-d54e-4f2f-8ee2-0d1381c9f955@github.com> On Sat, 6 Sep 2025 01:09:04 GMT, Weijun Wang wrote: >> Ah, yes. Comment does not align with the code. I am fine either way too. > > Either is OK. `Optional` sounds more modern and forces me to consider the empty case. Fixed the comment to agree with the code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2330771936 From duke at openjdk.org Mon Sep 8 16:36:58 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 8 Sep 2025 16:36:58 GMT Subject: RFR: 8366478: BigDecimal roots Message-ID: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> An implementation of `BigDecimal.nthRoot(int, MathContext)`. ------------- Commit messages: - Removed trailing whitespaces - Add BigDecimal.nthRoot() Changes: https://git.openjdk.org/jdk/pull/27148/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366478 Stats: 275 lines in 1 file changed: 91 ins; 116 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/27148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148 PR: https://git.openjdk.org/jdk/pull/27148 From ihse at openjdk.org Mon Sep 8 16:51:23 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 8 Sep 2025 16:51:23 GMT Subject: Integrated: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. This pull request has now been integrated. Changeset: 55af9d83 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/55af9d83800930966776224bc4c7ff4ab1af9817 Stats: 1321 lines in 9 files changed: 523 ins; 562 del; 236 mod 8366837: Clean up gensrc by spp.Spp Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/27078 From duke at openjdk.org Mon Sep 8 16:54:11 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 8 Sep 2025 16:54:11 GMT Subject: RFR: 8366478: BigDecimal roots In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> Message-ID: On Mon, 8 Sep 2025 16:25:00 GMT, fabioromano1 wrote: > An implementation of `BigDecimal.nthRoot(int, MathContext)`. @rgiulietti Here is the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3267146884 From rriggs at openjdk.org Mon Sep 8 16:54:18 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 8 Sep 2025 16:54:18 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v15] In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 14:50:56 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Use a different native method for testNative, since the implementation of forName has changed. Thanks for the updates and expanded tests. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26802#pullrequestreview-3197343416 From duke at openjdk.org Mon Sep 8 18:00:20 2025 From: duke at openjdk.org (xxDark) Date: Mon, 8 Sep 2025 18:00:20 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. Hello, this seemingly broke the build on Windows x64. VarHandleGuards class does not get generated. ^ f:\openjdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:558: error: cannot find symbol VarHandleGuards.class, getVarHandleGuardMethodName(guardType), ^ symbol: class VarHandleGuards location: class MethodHandleNatives f:\openjdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:562: error: cannot find symbol VarHandleGuards.class, LM_TRUSTED); ^ symbol: class VarHandleGuards location: class MethodHandleNatives f:\openjdk\src\java.base\share\classes\java\lang\invoke\VarHandle.java:2249: error: cannot find symbol UNSAFE.ensureClassInitialized(VarHandleGuards.class) Reverting this commit fixed the issue. The setup to configure the build was as follows: set JAVA_HOME=D:\jdks\temurin-24.0.32 d:\MSV2019\VC\Auxiliary\Build\vcvars64.bat d:\cygwin64\Cygwin.bat cd /cygdrive/f/openjdk bash configure make java.base $ make clean java.base Building targets 'clean java.base' in configuration 'windows-x86_64-server-release' Cleaning hotspot build artifacts ... done Cleaning jdk build artifacts ... done Cleaning bootcycle-build build artifacts ... done Cleaning test-results build artifacts ... done Cleaning test-support build artifacts ... done Cleaning test build artifacts ... done Cleaning buildtools build artifacts ... done Cleaning support build artifacts ... done Cleaning support/images build artifacts ... done Cleaning images build artifacts ... done Cleaning make-support build artifacts ... done Cleaning test-make build artifacts ... done Cleaning bundles build artifacts ... done Cleaning buildjdk build artifacts ... done Cleaned all build artifacts. Compiling up to 1 files for BUILD_TOOLS_HOTSPOT Compiling up to 9 files for BUILD_TOOLS_LANGTOOLS Generating classes for compiler.properties launcher.properties Compiling 17 properties into resource bundles for jdk.javadoc Generating FlagsEnum Compiling 19 properties into resource bundles for jdk.compiler Compiling up to 136 files for BUILD_java.compiler.interim Compiling up to 360 files for BUILD_jdk.compiler.interim Compiling up to 145 files for BUILD_jdk.internal.md.interim Compiling up to 213 files for BUILD_jdk.javadoc.interim Compiling up to 17 files for BUILD_JAVAC_SERVER Compiling up to 190 files for BUILD_TOOLS_JDK Compiling up to 2 files for COMPILE_DEPEND Compiling up to 2 files for BUILD_BREAKITERATOR_BASE Compiling up to 2 files for BUILD_BREAKITERATOR_LD SocketOptionRegistry.java.template d:\msvwin10kit\include\10.0.19041.0\um\winbase.h(9531): warning C5105: macro expansion producing 'defined' has undefined behavior Compiling 11 properties into resource bundles for java.base Compiling 3 properties into resource bundles for java.base Compiling 22 properties into resource bundles for java.base Compiling 11 properties into resource bundles for java.base Compiling up to 3366 files for java.base Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) Compiling up to 2 files for BUILD_JVMTI_TOOLS Creating support/modules_libs/java.base/server/jvm.dll from 1223 file(s) f:\jdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:558: error: cannot find symbol VarHandleGuards.class, getVarHandleGuardMethodName(guardType), ^ symbol: class VarHandleGuards location: class MethodHandleNatives f:\jdk\src\java.base\share\classes\java\lang\invoke\MethodHandleNatives.java:562: error: cannot find symbol VarHandleGuards.class, LM_TRUSTED); ^ symbol: class VarHandleGuards location: class MethodHandleNatives f:\jdk\src\java.base\share\classes\java\lang\invoke\VarHandle.java:2249: error: cannot find symbol UNSAFE.ensureClassInitialized(VarHandleGuards.class); ^ symbol: class VarHandleGuards location: class VarHandle 3 errors make[3]: *** [CompileJavaModules.gmk:102: /cygdrive/f/jdk/build/windows-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1 make[2]: *** [make/Main.gmk:182: java.base-java] Error 2 make[2]: *** Waiting for unfinished jobs.... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267328044 From liach at openjdk.org Mon Sep 8 18:06:15 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Sep 2025 18:06:15 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v15] In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 14:50:56 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Use a different native method for testNative, since the implementation of forName has changed. The production code looks good. Tests seem to be too reliant on the exact exception message (which is deemed an antipattern sometimes) but I think we can tweak those tests when they run into problems due to other changes later. src/java.base/share/classes/java/lang/Class.java line 4162: > 4160: if (!ModifiedUtf.isValidLengthInConstantPool(name)) { > 4161: throw new ClassNotFoundException( > 4162: "Class name length exceeds limit of " + ModifiedUtf.CONSTANT_POOL_UTF8_MAX_BYTES); Suggestion: "Class name length exceeds limit of " + ModifiedUtf.CONSTANT_POOL_UTF8_MAX_BYTES + ": " + name); ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26802#pullrequestreview-3194575026 PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2328827911 From liach at openjdk.org Mon Sep 8 18:09:18 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Sep 2025 18:09:18 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 20:17:50 GMT, Magnus Ihse Bursie wrote: > Several java classes in java.base is generated from templates using SPP, the "Stream Preprocessor". Unfortunately much of this code is very old and has survived unchanged since pre-JDK 7. It does not follow modern makefile standards for abstraction, safe coding practices, etc. In short, they have been a thorn in the side for a long time, and the time has finally come to clean them up. This patch removed the `VARHANDLES_GENSRC_DIR` variable used by VarHandleGuards generation. I think it can be addressed by a hot fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267361378 From alanb at openjdk.org Mon Sep 8 18:27:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Sep 2025 18:27:19 GMT Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang wrote: > This patch removed the `VARHANDLES_GENSRC_DIR` variable used by VarHandleGuards generation. I think it can be addressed by a hot fix. I think the change needs to backed out and the differences with line numbers checked to see what impact it will have on stack traces and mapping it back to the sources in the template files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267427085 From philip.race at oracle.com Mon Sep 8 18:52:43 2025 From: philip.race at oracle.com (Philip Race) Date: Mon, 8 Sep 2025 11:52:43 -0700 Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: Looks like it broke all the builds. So a P1 backout is needed. -phil. On 9/8/25 11:27 AM, Alan Bateman wrote: > On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang wrote: > >> This patch removed the `VARHANDLES_GENSRC_DIR` variable used by VarHandleGuards generation. I think it can be addressed by a hot fix. > I think the change needs to backed out and the differences with line numbers checked to see what impact it will have on stack traces and mapping it back to the sources in the template files. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/27078#issuecomment-3267427085 From philip.race at oracle.com Mon Sep 8 19:10:47 2025 From: philip.race at oracle.com (Philip Race) Date: Mon, 8 Sep 2025 12:10:47 -0700 Subject: RFR: 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: <311b7575-95d9-45e1-8146-bf9dd77dc2da@oracle.com> I submitted a bug report : https://bugs.openjdk.org/browse/JDK-8367130 -phil. On 9/8/25 11:52 AM, Philip Race wrote: > Looks like it broke all the builds. So a P1 backout is needed. > > -phil. > > On 9/8/25 11:27 AM, Alan Bateman wrote: >> On Mon, 8 Sep 2025 18:06:54 GMT, Chen Liang wrote: >> >>> This patch removed the `VARHANDLES_GENSRC_DIR` variable used by >>> VarHandleGuards generation. I think it can be addressed by a hot fix. >> I think the change needs to backed out and the differences with line >> numbers checked to see what impact it will have on stack traces and >> mapping it back to the sources in the template files. >> >> ------------- >> >> PR Comment: >> https://git.openjdk.org/jdk/pull/27078#issuecomment-3267427085 > From erikj at openjdk.org Mon Sep 8 19:57:21 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Sep 2025 19:57:21 GMT Subject: RFR: 8367130: JDK builds broken by 8366837: Clean up gensrc by spp.Spp Message-ID: Builds on all platforms are currently broken due to a clash between [JDK-8366837](https://bugs.openjdk.org/browse/JDK-8366837) and [JDK-8366455](https://bugs.openjdk.org/browse/JDK-8366455). The former changed the name of a variable that the latter introduced a new usage of. The fix is simple, just change the usage of the variable to the new name. I'm running a quick verification in internal CI. ------------- Commit messages: - JDK-8367130 Changes: https://git.openjdk.org/jdk/pull/27150/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27150&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367130 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27150.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27150/head:pull/27150 PR: https://git.openjdk.org/jdk/pull/27150 From liach at openjdk.org Mon Sep 8 20:16:10 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Sep 2025 20:16:10 GMT Subject: RFR: 8367130: JDK builds broken by 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 19:50:48 GMT, Erik Joelsson wrote: > Builds on all platforms are currently broken due to a clash between [JDK-8366837](https://bugs.openjdk.org/browse/JDK-8366837) and [JDK-8366455](https://bugs.openjdk.org/browse/JDK-8366455). The former changed the name of a variable that the latter introduced a new usage of. The fix is simple, just change the usage of the variable to the new name. > > I'm running a quick verification in internal CI. Thanks for this quick fix. We can investigate generated class parity later. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27150#pullrequestreview-3197998413 From rriggs at openjdk.org Mon Sep 8 20:52:09 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 8 Sep 2025 20:52:09 GMT Subject: RFR: 8367027: java/lang/ProcessBuilder/Basic.java fails on Windows AArch64 In-Reply-To: References: Message-ID: On Sat, 6 Sep 2025 20:44:55 GMT, Saint Wesonga wrote: > This test fails with errors like >'=C:=,=ExitValue=3,PROCESSOR_ARCHITECTURE=ARM64,SystemRoot=C:\Windows,'< not equal to '=C:=,=ExitValue=3,SystemRoot=C:\Windows,' > > The test does not expect the PROCESSOR_ARCHITECTURE variable to be returned from the ProcessBuilder (called at https://github.com/openjdk/jdk/blob/431f46724658b703e995e518cb7a2149c50d6a9d/test/jdk/java/lang/ProcessBuilder/Basic.java#L127 for example). The fix is to treat it as an expected variable and strip it out from the results, similar to how macOS and AIX strip out their expected variables. > > The winEnvFilter method needs to be updated because some checks like https://github.com/openjdk/jdk/blob/431f46724658b703e995e518cb7a2149c50d6a9d/test/jdk/java/lang/ProcessBuilder/Basic.java#L1694 have the output on separate lines as opposed to the inline comma-separated format where removeWindowsAArch64ExpectedVars is used. Look fine. I can't think but there might be a cleaner way to refactor the code, but this works and is similar to the existing adhoc fixups. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27131#pullrequestreview-3198132573 From erikj at openjdk.org Mon Sep 8 20:55:15 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Sep 2025 20:55:15 GMT Subject: Integrated: 8367130: JDK builds broken by 8366837: Clean up gensrc by spp.Spp In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 19:50:48 GMT, Erik Joelsson wrote: > Builds on all platforms are currently broken due to a clash between [JDK-8366837](https://bugs.openjdk.org/browse/JDK-8366837) and [JDK-8366455](https://bugs.openjdk.org/browse/JDK-8366455). The former changed the name of a variable that the latter introduced a new usage of. The fix is simple, just change the usage of the variable to the new name. > > I'm running a quick verification in internal CI. This pull request has now been integrated. Changeset: 56e37352 Author: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/56e37352d5b0a749ccd150c36c9248e37d280eb6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8367130: JDK builds broken by 8366837: Clean up gensrc by spp.Spp Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/27150 From duke at openjdk.org Mon Sep 8 21:18:09 2025 From: duke at openjdk.org (duke) Date: Mon, 8 Sep 2025 21:18:09 GMT Subject: RFR: 8367027: java/lang/ProcessBuilder/Basic.java fails on Windows AArch64 In-Reply-To: References: Message-ID: <3_rP0yHFyoWqDEF4ooLOs-B33fm6eNVqDWNrQ87exzk=.65612f40-dc4e-4959-b828-6d92939e26ee@github.com> On Sat, 6 Sep 2025 20:44:55 GMT, Saint Wesonga wrote: > This test fails with errors like >'=C:=,=ExitValue=3,PROCESSOR_ARCHITECTURE=ARM64,SystemRoot=C:\Windows,'< not equal to '=C:=,=ExitValue=3,SystemRoot=C:\Windows,' > > The test does not expect the PROCESSOR_ARCHITECTURE variable to be returned from the ProcessBuilder (called at https://github.com/openjdk/jdk/blob/431f46724658b703e995e518cb7a2149c50d6a9d/test/jdk/java/lang/ProcessBuilder/Basic.java#L127 for example). The fix is to treat it as an expected variable and strip it out from the results, similar to how macOS and AIX strip out their expected variables. > > The winEnvFilter method needs to be updated because some checks like https://github.com/openjdk/jdk/blob/431f46724658b703e995e518cb7a2149c50d6a9d/test/jdk/java/lang/ProcessBuilder/Basic.java#L1694 have the output on separate lines as opposed to the inline comma-separated format where removeWindowsAArch64ExpectedVars is used. @swesonga Your change (at version 7295f7eb94f5293d8f91b65cfc1f4217c4023a1b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27131#issuecomment-3268045944 From ghan at openjdk.org Tue Sep 9 01:05:37 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 9 Sep 2025 01:05:37 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v16] In-Reply-To: References: Message-ID: <-BkePe544FgYOqAXdW3apKhLEro5_7rtBkvVs9CjoNA=.6e8eb1b8-fd4a-4e79-a90b-2881a3ab774a@github.com> > Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update Class.java Improve error log ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26802/files - new: https://git.openjdk.org/jdk/pull/26802/files/2ca6354a..acc85bd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26802&range=14-15 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26802/head:pull/26802 PR: https://git.openjdk.org/jdk/pull/26802 From ghan at openjdk.org Tue Sep 9 01:05:40 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 9 Sep 2025 01:05:40 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v15] In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 20:09:53 GMT, Chen Liang wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Use a different native method for testNative, since the implementation of forName has changed. > > src/java.base/share/classes/java/lang/Class.java line 4162: > >> 4160: if (!ModifiedUtf.isValidLengthInConstantPool(name)) { >> 4161: throw new ClassNotFoundException( >> 4162: "Class name length exceeds limit of " + ModifiedUtf.CONSTANT_POOL_UTF8_MAX_BYTES); > > Suggestion: > > "Class name length exceeds limit of " + ModifiedUtf.CONSTANT_POOL_UTF8_MAX_BYTES + ": " + name); @liach Thanks for the suggestion. I think including the name is useful, but since it can be extremely long in this case, I?d prefer to log only the first part (e.g. first 256 chars + ???) to give context without flooding the logs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26802#discussion_r2331704563 From liach at openjdk.org Tue Sep 9 02:39:18 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Sep 2025 02:39:18 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v16] In-Reply-To: <-BkePe544FgYOqAXdW3apKhLEro5_7rtBkvVs9CjoNA=.6e8eb1b8-fd4a-4e79-a90b-2881a3ab774a@github.com> References: <-BkePe544FgYOqAXdW3apKhLEro5_7rtBkvVs9CjoNA=.6e8eb1b8-fd4a-4e79-a90b-2881a3ab774a@github.com> Message-ID: On Tue, 9 Sep 2025 01:05:37 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java > > Improve error log Sure, though this truncation may be wrong with over-one-byte characters (like ? or Chinese characters) but we don't need to be too strict about this. (Though I personally don't believe such will occur frequently in logs, which usually indicate a bad programming pattern instead) ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26802#pullrequestreview-3198826978 From ghan at openjdk.org Tue Sep 9 03:48:19 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 9 Sep 2025 03:48:19 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v12] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 18:40:26 GMT, Roger Riggs wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Class.java >> >> change overflow check > >> /reviewers 2 reviewer >> >> I recommend putting this PR on hold - 65535 encoded size for modified utf8 is significant enough for a cross-JDK utility. As @rose00 suggested, I think I will explore adding a check in ClassFile API, and sharing the check with here. > > A common boolean function is useful and can be better optimized. > The function should be in a common utility area, but the ClassFile API is a higher level API specific to class files. > Most developers won't think to look there. The jdk.internal.util.ModifiedUtf isn't a bad place for both the boolean function and the utfLen function. Hi @RogerRiggs, I?ve made further improvements to the error log , since this PR requires two approvals to merge, could you please review and approve it as well ? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3268761091 From fyang at openjdk.org Tue Sep 9 04:09:26 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 9 Sep 2025 04:09:26 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes > We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. > > Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. > > Internally it went through Oracle's tier1-8 without any issue again (that is revision [b3873d6](https://github.com/openjdk/jdk/commit/b3873d66cd43518d5dc71e060fc52a13372dbfa5), but the changes since then were very cosmetic). Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3268789193 From smarks at openjdk.org Tue Sep 9 04:47:11 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 9 Sep 2025 04:47:11 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v6] In-Reply-To: References: Message-ID: <5G_q7CDPPcLuo8d8C3GyeJht2Za6lM8-zFmXPu6BRoY=.07193205-3fc5-494d-922f-7e2999ea5e87@github.com> On Mon, 8 Sep 2025 16:34:29 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Looks good. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26973#pullrequestreview-3199187546 From jpai at openjdk.org Tue Sep 9 07:25:10 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Sep 2025 07:25:10 GMT Subject: RFR: 8367157: Remove jrunscript tool Message-ID: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157. `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests. tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note. ------------- Commit messages: - remove tests for jrunscript - remove jrunscript implementation - remove references from tests - remove man page for jrunscript Changes: https://git.openjdk.org/jdk/pull/27163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367157 Stats: 2364 lines in 24 files changed: 0 ins; 2360 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27163/head:pull/27163 PR: https://git.openjdk.org/jdk/pull/27163 From jpai at openjdk.org Tue Sep 9 07:44:05 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Sep 2025 07:44:05 GMT Subject: RFR: 8367157: Remove jrunscript tool In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> Message-ID: On Tue, 9 Sep 2025 07:18:25 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157. > > `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests. > > tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note. The CSR for this change is now ready for review https://bugs.openjdk.org/browse/JDK-8367229 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27163#issuecomment-3269343064 From epeter at openjdk.org Tue Sep 9 07:49:38 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 07:49:38 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: > 1487: @Test > 1488: @IR(failOn = IRNode.ALLOC) > 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail Can you explain what led to the difference? Can you also set an upper bound? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332346985 From rcastanedalo at openjdk.org Tue Sep 9 07:55:59 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 9 Sep 2025 07:55:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: <_sI2w99vG5BN7dhrgs-LabreQQG3r-7RaP6ejUls1_w=.ae0c7c90-87db-4136-b96f-d8b29ce8bdcf@github.com> On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes The compiler changes (including the x64 and aarch64 platform-specific code) still look good, thanks for this work! ------------- Marked as reviewed by rcastanedalo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3199884440 From jpai at openjdk.org Tue Sep 9 08:11:15 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Sep 2025 08:11:15 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v4] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? > > As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. > > The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. > > A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. > > tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - remove format() call in exception message creation - merge latest from master branch - merge latest from master branch - merge latest from master branch - add test - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25449/files - new: https://git.openjdk.org/jdk/pull/25449/files/545c41a1..5d6c2fdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25449&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25449&range=02-03 Stats: 96717 lines in 2693 files changed: 56785 ins; 27619 del; 12313 mod Patch: https://git.openjdk.org/jdk/pull/25449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25449/head:pull/25449 PR: https://git.openjdk.org/jdk/pull/25449 From jpai at openjdk.org Tue Sep 9 08:11:20 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Sep 2025 08:11:20 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v3] In-Reply-To: References: <3srnJrm0Np7t0RzwkM2lKK9SuMWyQ1EeAR5m65EaD8I=.e1d7ae14-9117-437c-a3a6-027a76146a84@github.com> Message-ID: On Wed, 6 Aug 2025 05:15:46 GMT, Shaojin Wen wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - merge latest from master branch >> - merge latest from master branch >> - add test >> - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed > > src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 87: > >> 85: ber.parseSeq(null); >> 86: ber.parseInt(); >> 87: isLdapResResult = (ber.peekByte() == LdapClient.LDAP_REP_RESULT); > > Other boolean type variables in the LdapRequest class do not have the `is` prefix. The local variable `isLdapResResult` here should also use the same style. We should not use two styles in one class. Calling it `ldapResResult` instead of `isLdapResResult` isn't appropriate here, so I've let this stay in its current form. > src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java line 147: > >> 145: } >> 146: if (result == CANCELLED_MARKER) { >> 147: throw new CommunicationException("Request: " + msgId + > > The current LdapRequest class should use a unified style to construct exception information, either using string concatenation or String.format. A class should not mix the two styles. Hello Shaojin, these are pre-existing messages. I have however updated the PR to use a uniform style. > test/jdk/javax/naming/ldap/LdapClientConnTest.java line 110: > >> 108: try (final ExecutorService executor = Executors.newCachedThreadPool()) { >> 109: for (int i = 1; i <= numTasks; i++) { >> 110: final String taskName = "task-" + i; > > Suggestion: > > String taskName = "task-" + i; > > Variables used only in the current block do not need to be final This a more a personal preference and since this is a new test file, I let it stay in this form. If there's a strong preference to remove it, I'll do so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2332405116 PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2332402149 PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2332413316 From swen at openjdk.org Tue Sep 9 08:13:40 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 9 Sep 2025 08:13:40 GMT Subject: Withdrawn: Re-examine buffering and encoding conversion in BufferedWriter In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 16:48:40 GMT, Shaojin Wen wrote: > BufferedWriter -> OutputStreamWriter -> StreamEncoder > > In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. > > LATIN1 -> UTF16 -> UTF8 > > We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26022 From epeter at openjdk.org Tue Sep 9 08:45:30 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 08:45:30 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:13:28 GMT, erifan wrote: > Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. > > Benchmarks on Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 > microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 > microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 > microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 > microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 > microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 > microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 > microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 > microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 > microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 > > > Benchmarks on Intel 6444y machine with 512-bit avx3: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 > microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 > microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 > microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 > microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 > microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 > microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 > microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 > microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 > microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 > microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 > microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 > microMaskLane... @erifan This is a regression / bug fix for https://github.com/openjdk/jdk/pull/25673, right? If so, please convert the JBS issue into a bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27113#issuecomment-3269564806 From epeter at openjdk.org Tue Sep 9 08:51:21 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 08:51:21 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:13:28 GMT, erifan wrote: > Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. > > Benchmarks on Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 > microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 > microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 > microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 > microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 > microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 > microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 > microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 > microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 > microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 > > > Benchmarks on Intel 6444y machine with 512-bit avx3: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 > microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 > microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 > microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 > microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 > microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 > microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 > microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 > microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 > microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 > microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 > microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 > microMaskLane... The patch looks reasonable, thanks for fixing this and writing an IR test! I'm launching some internal testing now, should hopefully not take much more than 24h. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27113#issuecomment-3269585613 From xgong at openjdk.org Tue Sep 9 09:17:14 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 9 Sep 2025 09:17:14 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:13:28 GMT, erifan wrote: > Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. > > Benchmarks on Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 > microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 > microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 > microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 > microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 > microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 > microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 > microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 > microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 > microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 > > > Benchmarks on Intel 6444y machine with 512-bit avx3: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 > microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 > microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 > microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 > microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 > microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 > microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 > microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 > microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 > microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 > microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 > microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 > microMaskLane... > @erifan This is a regression / bug fix for #25673, right? If so, please convert the JBS issue into a bug. Thanks for your review! I'v changed the JBS type to bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27113#issuecomment-3269685052 From xgong at openjdk.org Tue Sep 9 09:33:34 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 9 Sep 2025 09:33:34 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:13:28 GMT, erifan wrote: > Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. > > Benchmarks on Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 > microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 > microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 > microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 > microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 > microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 > microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 > microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 > microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 > microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 > > > Benchmarks on Intel 6444y machine with 512-bit avx3: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 > microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 > microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 > microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 > microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 > microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 > microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 > microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 > microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 > microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 > microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 > microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 > microMaskLane... LGTM! ------------- Marked as reviewed by xgong (Committer). PR Review: https://git.openjdk.org/jdk/pull/27113#pullrequestreview-3200414898 From duke at openjdk.org Tue Sep 9 09:33:35 2025 From: duke at openjdk.org (erifan) Date: Tue, 9 Sep 2025 09:33:35 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 08:48:42 GMT, Emanuel Peter wrote: >> Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 >> microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 >> microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 >> microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 >> microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 >> microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 >> microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 >> microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 >> microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 >> microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 >> >> >> Benchmarks on Intel 6444y machine with 512-bit avx3: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 >> microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 >> microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 >> microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 >> microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 >> microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 >> microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 >> microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 >> microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 >> microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 >> microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 >> microMaskLaneIsSetInt512_var ops/ms 573... > > The patch looks reasonable, thanks for fixing this and writing an IR test! > I'm launching some internal testing now, should hopefully not take much more than 24h. Thanks for your help @eme64 @XiaohongGong @shipilev ------------- PR Comment: https://git.openjdk.org/jdk/pull/27113#issuecomment-3269744719 From duke at openjdk.org Tue Sep 9 10:15:02 2025 From: duke at openjdk.org (Johny Jose) Date: Tue, 9 Sep 2025 10:15:02 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v2] In-Reply-To: References: Message-ID: > Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 Johny Jose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8365398 - 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26815/files - new: https://git.openjdk.org/jdk/pull/26815/files/c1974740..78d3efbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26815&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26815&range=00-01 Stats: 43938 lines in 1688 files changed: 25882 ins; 10731 del; 7325 mod Patch: https://git.openjdk.org/jdk/pull/26815.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26815/head:pull/26815 PR: https://git.openjdk.org/jdk/pull/26815 From duke at openjdk.org Tue Sep 9 10:39:27 2025 From: duke at openjdk.org (Tatsunori Uchino) Date: Tue, 9 Sep 2025 10:39:27 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino wrote: >> 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? > > Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision: > > - Update `@bug` in correct file > - Add default implementation on codePointCount in CharSequence > - Update `@bug` entries in test class doc comments > - Discard changes on code whose form is not `str.codePointCount(0, str.length())` What should _I_ do now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3270063910 From stefank at openjdk.org Tue Sep 9 11:20:11 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 11:20:11 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: <48KBVP1dUIm4u54Deyd86JjTvGWYgVFpVNcZpByQcxM=.43aac7fb-2918-4e66-ac00-b734c0a871b8@github.com> On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27086#issuecomment-3270221506 From stefank at openjdk.org Tue Sep 9 11:20:13 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 11:20:13 GMT Subject: Integrated: 8366854: Extend jtreg failure handler with THP info In-Reply-To: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: <7Nwy3L2GxuSImNvYy6bSE8aqD4miLiZF9HjeE47UpYk=.1851f7d8-1006-4f0d-8e40-bf9aa698e7f3@github.com> On Thu, 4 Sep 2025 07:03:01 GMT, Stefan Karlsson wrote: > I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. > > This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. This pull request has now been integrated. Changeset: a1ab12b7 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/a1ab12b77266c7124a297e1b2e0a8608b8facb2a Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8366854: Extend jtreg failure handler with THP info Reviewed-by: ayang, shade, tschatzl, lmesnik, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/27086 From ihse at openjdk.org Tue Sep 9 11:46:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 9 Sep 2025 11:46:21 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v5] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'master' into static-relaunchers - Use ReadFile instead - Merge branch 'master' into static-relaunchers - Remove problemlisting - Merge branch 'master' into static-relaunchers - Improve windows runtime lib copying - Fix linux launcher to allow relaunching - Copy Windows runtime libs - Merge branch 'master' into static-relaunchers - Merge branch 'master' into static-relaunchers - ... and 7 more: https://git.openjdk.org/jdk/compare/06326176...41b5030b ------------- Changes: https://git.openjdk.org/jdk/pull/24380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=04 Stats: 817 lines in 14 files changed: 628 ins; 143 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From msheppar at openjdk.org Tue Sep 9 11:48:52 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 9 Sep 2025 11:48:52 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 10:15:02 GMT, Johny Jose wrote: >> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 > > Johny Jose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8365398 > - 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently test/jdk/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java line 130: > 128: /* numLeft should be 6 - if 11 there is a problem. */ > 129: if (numLeft > 6) { > 130: TestLibrary.bomb("Too many objects in DGCImpl.leaseTable: "+ This doesn't solve the problem, the structure of the test is problematic please c.f. comments in bug ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26815#discussion_r2333219528 From ihse at openjdk.org Tue Sep 9 13:15:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 9 Sep 2025 13:15:57 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v6] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update based on review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24380/files - new: https://git.openjdk.org/jdk/pull/24380/files/41b5030b..0ba27090 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=04-05 Stats: 41 lines in 3 files changed: 18 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From ihse at openjdk.org Tue Sep 9 13:15:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 9 Sep 2025 13:15:58 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v3] In-Reply-To: References: Message-ID: <9ViQUUyQ396N0y0_EChd4GDw1Ns9CPoPJLfQb2Zax5E=.5c72c24a-761f-42b3-88b2-8114e3470eef@github.com> On Mon, 11 Aug 2025 17:20:30 GMT, Erik Joelsson wrote: >> This solution was modeled on how we create `module-included-libs.txt`. I agree that it is a bit hacky to inject this kind of stuff in ModuleWrapper, but I can't see how we can do it more cleanly. That's the only point at which we know the entire module for a phase. >> >> Maybe we can improve optics by doing a more official-looking "hook" for injecting functionality at pre-/post- whole-module processing? That would keep ModuleWrapper slimmer and without all the current specialized hooks, and make the name "wrapper" more relevant. >> >> Or, we could rename the makefile to indicate better that it does a lot more than just wraps a file. (I have no good suggestions right now.) > > I'm not sure what you mean here. I described a solution that keeps it in LauncherCommon without creating races. @erikj79 I've finally gotten around to fixing this. Looks ok? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2333542410 From epeter at openjdk.org Tue Sep 9 13:16:59 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 13:16:59 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v11] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 06:08:33 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request incrementally with one additional commit since the last revision: > > Update the code comment Looks much better, thanks for the updates! I have another small list of suggestions :) src/hotspot/share/opto/vectornode.cpp line 2243: > 2241: if (in1->Opcode() != Op_VectorMaskCmp || > 2242: in1->outcnt() != 1 || > 2243: !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || Suggestion: !in1->as_VectorMaskCmp()->predicate_can_be_negated() || Brackets are unnecessary, and rather make it harder to read. src/hotspot/share/opto/vectornode.cpp line 2277: > 2275: res = VectorNode::Ideal(phase, can_reshape); > 2276: } > 2277: return res; What if someone comes and wants to add yet another optimization before `VectorNode::Ideal`? Your code layout would give us deeper and deeper nesting. I suggest flattening it like this: Suggestion: Node* res = Ideal_XorV_VectorMaskCmp(phase, can_reshape); if (res != nullptr) { return res; } return VectorNode::Ideal(phase, can_reshape); test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 911: > 909: testCompareMaskNotLong(L_SPECIES_FOR_CAST, VectorOperators.UGE, (m) -> { return m.cast(I_SPECIES_FOR_CAST).not(); }); > 910: verifyResultsLong(L_SPECIES_FOR_CAST, VectorOperators.UGE); > 911: } You have some cast in here, and in similar tests. Can you add an IR rule to check if we do or do not have the expected casts? test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 1007: > 1005: testCompareMaskNotFloat(F_SPECIES, VectorOperators.NE, fa, fninf, (m) -> { return F_SPECIES.maskAll(true).xor(m); }); > 1006: verifyResultsFloat(F_SPECIES, VectorOperators.NE, fa, fninf); > 1007: } Do you have test cases for the cases other than `EQ` and `NE`? After all, we don't that someone accidentally messes with the logic you implemented later and we don't notice the bug ;) test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 351: > 349: public void testCompareULEMaskNotLong() { > 350: testCompareMaskNotLong(VectorOperators.ULE); > 351: } You could consider making the operator a `@Param` next time. There are multiple tricks to do that: - `test/micro/org/openjdk/bench/vm/compiler/VectorStoreToLoadForwarding.java` using `MethodHandles.constant` - Some inner class that has a static final, which is initialized from the non-final `@Param` value. - Probably even `StableValue` would work, but I have not yet experimented with it. It would be nice if we could do the same with the primitive types, but that's probably not going to work as easily. Really just an idea for next time. test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 366: > 364: public void testCompareNEMaskNotFloat() { > 365: testCompareMaskNotFloat(VectorOperators.NE); > 366: } You could still add the other comparisons as well, so we can see the performance difference. Very optional, feel free to ignore this suggestion. ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-3201347660 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2333480061 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2333418237 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2333510278 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2333503735 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2333545924 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2333516350 From duke at openjdk.org Tue Sep 9 13:17:02 2025 From: duke at openjdk.org (Saint Wesonga) Date: Tue, 9 Sep 2025 13:17:02 GMT Subject: Integrated: 8367027: java/lang/ProcessBuilder/Basic.java fails on Windows AArch64 In-Reply-To: References: Message-ID: On Sat, 6 Sep 2025 20:44:55 GMT, Saint Wesonga wrote: > This test fails with errors like >'=C:=,=ExitValue=3,PROCESSOR_ARCHITECTURE=ARM64,SystemRoot=C:\Windows,'< not equal to '=C:=,=ExitValue=3,SystemRoot=C:\Windows,' > > The test does not expect the PROCESSOR_ARCHITECTURE variable to be returned from the ProcessBuilder (called at https://github.com/openjdk/jdk/blob/431f46724658b703e995e518cb7a2149c50d6a9d/test/jdk/java/lang/ProcessBuilder/Basic.java#L127 for example). The fix is to treat it as an expected variable and strip it out from the results, similar to how macOS and AIX strip out their expected variables. > > The winEnvFilter method needs to be updated because some checks like https://github.com/openjdk/jdk/blob/431f46724658b703e995e518cb7a2149c50d6a9d/test/jdk/java/lang/ProcessBuilder/Basic.java#L1694 have the output on separate lines as opposed to the inline comma-separated format where removeWindowsAArch64ExpectedVars is used. This pull request has now been integrated. Changeset: f10c85fb Author: Saint Wesonga Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/f10c85fbc336f6908a4f1ecae9fb5ab52984f636 Stats: 23 lines in 1 file changed: 21 ins; 0 del; 2 mod 8367027: java/lang/ProcessBuilder/Basic.java fails on Windows AArch64 Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/27131 From erikj at openjdk.org Tue Sep 9 13:30:49 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 Sep 2025 13:30:49 GMT Subject: RFR: 8367157: Remove jrunscript tool In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> Message-ID: On Tue, 9 Sep 2025 07:18:25 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157. > > `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests. > > tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27163#pullrequestreview-3201606997 From epeter at openjdk.org Tue Sep 9 13:37:27 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 13:37:27 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:13:28 GMT, erifan wrote: > Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. > > Benchmarks on Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 > microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 > microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 > microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 > microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 > microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 > microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 > microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 > microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 > microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 > > > Benchmarks on Intel 6444y machine with 512-bit avx3: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 > microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 > microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 > microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 > microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 > microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 > microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 > microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 > microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 > microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 > microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 > microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 > microMaskLane... Patch looks good to me, testing passed :) Thanks for working on this @erifan ! ------------- Marked as reviewed by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27113#pullrequestreview-3201642369 From mdoerr at openjdk.org Tue Sep 9 14:06:25 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 9 Sep 2025 14:06:25 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: <3t1NXG7f_TsOxvst83-A9dDPQ9ZOyl5ybNJDtpkhvAk=.671d5ae9-e32c-42de-a519-f52929495100@github.com> On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes Still works fine on SAP supported platforms (including PPC64). @RealFYang: Three way merge succeded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3270891086 From duke at openjdk.org Tue Sep 9 14:42:30 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 9 Sep 2025 14:42:30 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails Message-ID: The writer field of the handler needs to be re-checked for null inside the locked region before use. ------------- Commit messages: - Re-check writer after locking Changes: https://git.openjdk.org/jdk/pull/27173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365483 Stats: 10 lines in 1 file changed: 5 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27173/head:pull/27173 PR: https://git.openjdk.org/jdk/pull/27173 From dfuchs at openjdk.org Tue Sep 9 14:42:30 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 9 Sep 2025 14:42:30 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 14:25:00 GMT, David Beaumont wrote: > The writer field of the handler needs to be re-checked for null inside the locked region before use. LGTM. Please run tier 2 before integrating. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27173#pullrequestreview-3201942066 From duke at openjdk.org Tue Sep 9 14:54:12 2025 From: duke at openjdk.org (fabioromano1) Date: Tue, 9 Sep 2025 14:54:12 GMT Subject: RFR: 8366478: BigDecimal roots [v2] In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> Message-ID: > An implementation of `BigDecimal.nthRoot(int, MathContext)`. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Code simplification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27148/files - new: https://git.openjdk.org/jdk/pull/27148/files/e8b373d3..9ba939c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148 PR: https://git.openjdk.org/jdk/pull/27148 From liach at openjdk.org Tue Sep 9 15:08:06 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Sep 2025 15:08:06 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino wrote: >> 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? > > Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision: > > - Update `@bug` in correct file > - Add default implementation on codePointCount in CharSequence > - Update `@bug` entries in test class doc comments > - Discard changes on code whose form is not `str.codePointCount(0, str.length())` I think this is a good proposal. We can move forward and leave some discussions: 1. Is it necessary to have both `Character.codePointCount(CharSequence)` and `CharSequence.codePointCount`? 2. Do we need `codePointCount(int start, int end)` in CharSequence too? For `CharSequence.codePointCount`, as Alan Bateman said, we need to check for compatibility, which I can help after settle down with the API shape. In addition, `CharBuffer` needs to document its `CharSequence` methods as "Relative ...." operations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3271140920 From duke at openjdk.org Tue Sep 9 15:25:05 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 9 Sep 2025 15:25:05 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v2] In-Reply-To: References: Message-ID: > The writer field of the handler needs to be re-checked for null inside the locked region before use. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Adding test (thanks Jai) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27173/files - new: https://git.openjdk.org/jdk/pull/27173/files/6738848b..2992350f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27173&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27173&range=00-01 Stats: 139 lines in 1 file changed: 139 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27173/head:pull/27173 PR: https://git.openjdk.org/jdk/pull/27173 From weijun at openjdk.org Tue Sep 9 15:29:44 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 Sep 2025 15:29:44 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 16:34:29 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 137: > 135: } > 136: > 137: // Dedicated entry for sun.security.util.Password. To be more clear, I suggest this comment: // Dedicated entry for sun.security.util.Password when stdout is redirected. // This method strictly avoids producing any output by using noNewLine = true // and an empty format string. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2334014703 From duke at openjdk.org Tue Sep 9 15:31:40 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 9 Sep 2025 15:31:40 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v3] In-Reply-To: References: Message-ID: > The writer field of the handler needs to be re-checked for null inside the locked region before use. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: License fix. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27173/files - new: https://git.openjdk.org/jdk/pull/27173/files/2992350f..213361cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27173&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27173&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27173/head:pull/27173 PR: https://git.openjdk.org/jdk/pull/27173 From dfuchs at openjdk.org Tue Sep 9 15:31:44 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 9 Sep 2025 15:31:44 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:25:05 GMT, David Beaumont wrote: >> The writer field of the handler needs to be re-checked for null inside the locked region before use. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Adding test (thanks Jai) Thanks for adding that test @david-beaumont ! The license header needs to be fixed though. test/jdk/java/util/logging/StreamHandlerRacyCloseTest.java line 9: > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided > 9: * by Oracle in the LICENSE file that accompanied this code. Tests should not have the "Classpath" exception. test/jdk/java/util/logging/StreamHandlerRacyCloseTest.java line 139: > 137: } > 138: } > 139: } Please fix newlines at the end. ------------- Changes requested by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27173#pullrequestreview-3202149911 PR Review Comment: https://git.openjdk.org/jdk/pull/27173#discussion_r2334004641 PR Review Comment: https://git.openjdk.org/jdk/pull/27173#discussion_r2334004313 From duke at openjdk.org Tue Sep 9 15:31:44 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 9 Sep 2025 15:31:44 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:23:43 GMT, Daniel Fuchs wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding test (thanks Jai) > > test/jdk/java/util/logging/StreamHandlerRacyCloseTest.java line 9: > >> 7: * published by the Free Software Foundation. Oracle designates this >> 8: * particular file as subject to the "Classpath" exception as provided >> 9: * by Oracle in the LICENSE file that accompanied this code. > > Tests should not have the "Classpath" exception. Ahh thanks, didn't realize they could not just be copied from source files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27173#discussion_r2334012610 From dfuchs at openjdk.org Tue Sep 9 15:52:37 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 9 Sep 2025 15:52:37 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:31:40 GMT, David Beaumont wrote: >> The writer field of the handler needs to be re-checked for null inside the locked region before use. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > License fix. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27173#pullrequestreview-3202262299 From jpai at openjdk.org Tue Sep 9 16:24:12 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Sep 2025 16:24:12 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:31:40 GMT, David Beaumont wrote: >> The writer field of the handler needs to be re-checked for null inside the locked region before use. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > License fix. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27173#pullrequestreview-3202374364 From asmehra at openjdk.org Tue Sep 9 16:49:12 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 9 Sep 2025 16:49:12 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 21:17:42 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > - @DanHeidinga comments > - tightened SystemDictionary::preload_class() > - Fixed bugs found in JCK > - added entry in ProblemList-AotJdk.txt due to 8323727 > - more clean up > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 src/hotspot/share/cds/aotOopChecker.cpp line 53: > 51: // the production run. > 52: void AOTOopChecker::check(oop obj) { > 53: precond(vmClasses::URL_klass()->is_final()); `AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects. src/hotspot/share/cds/aotOopChecker.cpp line 55: > 53: precond(vmClasses::URL_klass()->is_final()); > 54: > 55: if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) { URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient? src/hotspot/share/classfile/javaClasses.cpp line 1063: > 1061: > 1062: // Statically allocate fixup lists because they always get created. > 1063: void java_lang_Class::allocate_fixup_lists() { Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? src/hotspot/share/memory/iterator.inline.hpp line 58: > 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); > 57: } else { > 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); Why is the null check and assert not valid anymore? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2331108015 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124611 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124798 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334211674 From duke at openjdk.org Tue Sep 9 16:55:53 2025 From: duke at openjdk.org (duke) Date: Tue, 9 Sep 2025 16:55:53 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:31:40 GMT, David Beaumont wrote: >> The writer field of the handler needs to be re-checked for null inside the locked region before use. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > License fix. @david-beaumont Your change (at version 213361cbc8ec9e8fea40073dcb5e33ef3c4440ad) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27173#issuecomment-3271528595 From naoto at openjdk.org Tue Sep 9 17:10:10 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Sep 2025 17:10:10 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v7] In-Reply-To: References: Message-ID: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> > Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Comment refined ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26973/files - new: https://git.openjdk.org/jdk/pull/26973/files/9306bc0d..b928b2c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26973&range=05-06 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26973/head:pull/26973 PR: https://git.openjdk.org/jdk/pull/26973 From naoto at openjdk.org Tue Sep 9 17:10:13 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Sep 2025 17:10:13 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v6] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:27:20 GMT, Weijun Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments > > src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 137: > >> 135: } >> 136: >> 137: // Dedicated entry for sun.security.util.Password. > > To be more clear, I suggest this comment: > > // Dedicated entry for sun.security.util.Password when stdout is redirected. > // This method strictly avoids producing any output by using noNewLine = true > // and an empty format string. Thanks. Modified the comment as suggested ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26973#discussion_r2334255209 From erikj at openjdk.org Tue Sep 9 17:15:50 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 Sep 2025 17:15:50 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v6] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 13:15:57 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Update based on review Build changes look good thanks! ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24380#pullrequestreview-3202542309 From weijun at openjdk.org Tue Sep 9 17:25:49 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 9 Sep 2025 17:25:49 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v7] In-Reply-To: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> References: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> Message-ID: <7ezREAkghyYEPsi8Xn8e61sZQ-q5_WW7kBLiBVIJpwo=.58060fae-72ab-49d2-aee2-f5940b0b87ab@github.com> On Tue, 9 Sep 2025 17:10:10 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment refined Marked as reviewed by weijun (Reviewer). Thanks for the comment change. Approved. ------------- PR Review: https://git.openjdk.org/jdk/pull/26973#pullrequestreview-3202579185 PR Comment: https://git.openjdk.org/jdk/pull/26973#issuecomment-3271636611 From smarks at openjdk.org Tue Sep 9 17:32:41 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 9 Sep 2025 17:32:41 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v7] In-Reply-To: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> References: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> Message-ID: On Tue, 9 Sep 2025 17:10:10 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment refined Not sure whether I need to re-approve, but I will anyway! ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26973#pullrequestreview-3202602888 From duke at openjdk.org Tue Sep 9 19:19:22 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 9 Sep 2025 19:19:22 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v4] In-Reply-To: References: Message-ID: <6n_X3OHVCgQf4cn_-wSa43_CNVlkB5tA3b4ylohlb14=.a0d5de68-db13-4661-87b8-fe7e8add0543@github.com> > The writer field of the handler needs to be re-checked for null inside the locked region before use. David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into jdk_8365483/squashed - License fix. - Adding test (thanks Jai) - Re-check writer after locking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27173/files - new: https://git.openjdk.org/jdk/pull/27173/files/213361cb..d174f56d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27173&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27173&range=02-03 Stats: 51969 lines in 1862 files changed: 31292 ins; 12627 del; 8050 mod Patch: https://git.openjdk.org/jdk/pull/27173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27173/head:pull/27173 PR: https://git.openjdk.org/jdk/pull/27173 From naoto at openjdk.org Tue Sep 9 19:41:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Sep 2025 19:41:20 GMT Subject: RFR: 8366261: Provide utility methods for sun.security.util.Password [v7] In-Reply-To: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> References: <3OdIS9M5hb1VXBug8J5JebeyRODU9xrZQcpO3dukxz8=.ca1d0700-1580-4d12-b780-3bbbbc23d681@github.com> Message-ID: <1n1No4VjrH387wct3GaAcfW5SjpFpQOCuB8t3clKHKk=.10d66779-954b-42d8-a427-68ccbfc6d02f@github.com> On Tue, 9 Sep 2025 17:10:10 GMT, Naoto Sato wrote: >> Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment refined Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26973#issuecomment-3272029449 From naoto at openjdk.org Tue Sep 9 19:41:21 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Sep 2025 19:41:21 GMT Subject: Integrated: 8366261: Provide utility methods for sun.security.util.Password In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 22:53:28 GMT, Naoto Sato wrote: > Providing a couple of utility methods using the "built-in" `Console` implementation to support tools that require password input, such as `keytool`, ensuring they work even when std0ut is redirected. This pull request has now been integrated. Changeset: a12e9fce Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/a12e9fcebda1d7b75cb892e7920333d73fb5de9c Stats: 106 lines in 6 files changed: 81 ins; 0 del; 25 mod 8366261: Provide utility methods for sun.security.util.Password Reviewed-by: smarks, weijun ------------- PR: https://git.openjdk.org/jdk/pull/26973 From jlu at openjdk.org Tue Sep 9 22:07:29 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 9 Sep 2025 22:07:29 GMT Subject: Integrated: 8366733: Re-examine older java.text NF, DF, and DFS serialization tests In-Reply-To: References: Message-ID: <_TRTJnSWw4DkW6HveTcuQfX75R5GzZH1c6JQgJVTyrI=.06d4ac91-1ad8-4b15-b6b0-8b8513103bac@github.com> On Thu, 4 Sep 2025 22:03:51 GMT, Justin Lu wrote: > This PR cleans up the existing DecimalFormatSymbols, DecimalFormat, and NumberFormat serialization tests. > > As mentioned in https://github.com/openjdk/jdk/pull/27008 these tests can be re-visited. > > These older tests are either not run (since they rely on being run by older JDK versions), rely on hex dump files, or are simply outdated. These are now removed or updated and moved under **DecimalFormat/SerializationTest.java** and **DFSSerializationTest.java**. Additionally, tests to check the stream version invariants are added for DecimalFormat. > > Below are the existing tests that are removed or modified. (Their associated hex dump files are removed as well). > > **DFSDeserialization142.java & DFSSerialization142.java** (D) > > - They do not have Jtreg headers and are not run. The comments indicate they require a specific JDK version of 1.4.2. Instead, a currency symbol test is added in place. > > **NumberFormat/DFSSerialization.java** (D) > > - Test 1 checks if a DFS written from a 1.4.2 JDK with stream version of 2 when read has the correct String exponent and currency symbol. -> There is an existing test which checks the exponent. A New test is added in place of currency symbol test. > - Test 2 checks that a DFS maintains the exponent separator and currency symbol when read. -> Tests are added in place of them of them. > - Test 3 is unrelated to de serialization, and checks that the exponent separator symbol setter throws NPE. -> Test 3 is already covered by **SettersShouldThrowNPETest.java**. > > **SerializationLoad.java & SerializationSave.java** (D) > > - The save test depends on JDK 1.1.4, and is the code to write a DFS and DF. (It has no header and is not run.) The load test uses the saved 1.1.4 hex dump file to ensure the DFS and DF can be read, it did not check any specific invariants. > > **NumberRegression.java** (M) > > - Test4185761 and Test4069754 check NF/DF invariants and are ported to the dedicated serialization test file. This pull request has now been integrated. Changeset: 24a73493 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/24a734938e555882857cf0b06ea693ec6f18085f Stats: 940 lines in 13 files changed: 350 ins; 544 del; 46 mod 8366733: Re-examine older java.text NF, DF, and DFS serialization tests Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/27108 From duke at openjdk.org Wed Sep 10 01:49:14 2025 From: duke at openjdk.org (duke) Date: Wed, 10 Sep 2025 01:49:14 GMT Subject: RFR: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:13:28 GMT, erifan wrote: > Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. > > Benchmarks on Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 > microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 > microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 > microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 > microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 > microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 > microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 > microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 > microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 > microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 > > > Benchmarks on Intel 6444y machine with 512-bit avx3: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 > microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 > microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 > microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 > microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 > microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 > microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 > microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 > microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 > microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 > microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 > microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 > microMaskLane... @erifan Your change (at version a672dd26c6c7547bca260815ae2e1d7c3652c929) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27113#issuecomment-3272907016 From duke at openjdk.org Wed Sep 10 01:53:21 2025 From: duke at openjdk.org (erifan) Date: Wed, 10 Sep 2025 01:53:21 GMT Subject: Integrated: 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 08:13:28 GMT, erifan wrote: > Intrinsic support for `VectorMask.laneIsSet` with a **variable** input index was introduced in PR #14200, but was inadvertently broken by PR #25673. This PR restores the intrinsic functionality and adds some JTReg tests. > > Benchmarks on Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 21702.14415 91.902159 103472.9391 36.057447 4.767867 > microMaskLaneIsSetByte64_var ops/ms 21468.51868 107.94177 103365.6561 69.47736 4.814754 > microMaskLaneIsSetDouble128_var ops/ms 77489.32791 153.242699 413499.4127 311.854079 5.336211 > microMaskLaneIsSetFloat128_var ops/ms 41034.95204 399.421823 206840.0988 74.702234 5.040583 > microMaskLaneIsSetFloat64_var ops/ms 77607.40268 175.938921 413745.3001 149.716794 5.33126 > microMaskLaneIsSetInt128_var ops/ms 41452.48893 76.143208 206845.9754 59.371129 4.989953 > microMaskLaneIsSetInt64_var ops/ms 77726.2542 173.180518 413427.8838 363.575023 5.319024 > microMaskLaneIsSetLong128_var ops/ms 77646.11218 177.496587 413403.4404 236.609314 5.3242 > microMaskLaneIsSetShort128_var ops/ms 21374.93265 48.13101 103417.4618 34.827021 4.838259 > microMaskLaneIsSetShort64_var ops/ms 41066.19395 353.320621 206801.109 106.408938 5.035799 > > > Benchmarks on Intel 6444y machine with 512-bit avx3: > > Benchmark Unit Before Score Error After Score Error Uplift > microMaskLaneIsSetByte128_var ops/ms 57658.45497 240.209309 211643.8406 29.214532 3.670647 > microMaskLaneIsSetByte256_var ops/ms 57451.68169 116.994128 211609.4652 160.48513 3.683259 > microMaskLaneIsSetByte512_var ops/ms 57530.22411 311.63868 199802.8084 408.144015 3.473005 > microMaskLaneIsSetByte64_var ops/ms 57642.2672 161.406221 205252.4464 196.86852 3.560797 > microMaskLaneIsSetDouble256_var ops/ms 114401.3789 231.797375 361400.344 565.593984 3.159055 > microMaskLaneIsSetDouble512_var ops/ms 57379.27882 159.699503 211476.1138 136.980026 3.685583 > microMaskLaneIsSetFloat128_var ops/ms 113943.9512 141.062663 360855.3915 494.471996 3.166955 > microMaskLaneIsSetFloat256_var ops/ms 57682.78182 138.142053 211659.5098 30.167972 3.66937 > microMaskLaneIsSetFloat512_var ops/ms 57617.66405 301.748599 211246.8588 597.18949 3.666355 > microMaskLaneIsSetInt128_var ops/ms 113914.5062 118.681382 360856.4465 555.097397 3.167783 > microMaskLaneIsSetInt256_var ops/ms 57681.79883 112.391639 211555.6742 217.556981 3.667633 > microMaskLaneIsSetInt512_var ops/ms 57350.20346 206.146723 211657.7207 68.461571 3.690618 > microMaskLane... This pull request has now been integrated. Changeset: 53b3e056 Author: erifan Committer: Xiaohong Gong URL: https://git.openjdk.org/jdk/commit/53b3e0567d2801ddf62c5849b219324ddfcb264a Stats: 170 lines in 4 files changed: 168 ins; 0 del; 2 mod 8366588: VectorAPI: Re-intrinsify VectorMask.laneIsSet where the input index is a variable Reviewed-by: shade, xgong, epeter ------------- PR: https://git.openjdk.org/jdk/pull/27113 From iklam at openjdk.org Wed Sep 10 04:16:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:03 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - @ashu-mehra review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run - @DanHeidinga comments - tightened SystemDictionary::preload_class() - Fixed bugs found in JCK - added entry in ProblemList-AotJdk.txt due to 8323727 - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=06 Stats: 716 lines in 44 files changed: 602 ins; 13 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Wed Sep 10 04:16:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:07 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 18:57:16 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - more clean up >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 > > src/hotspot/share/cds/aotOopChecker.cpp line 53: > >> 51: // the production run. >> 52: void AOTOopChecker::check(oop obj) { >> 53: precond(vmClasses::URL_klass()->is_final()); > > `AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects. I moved this line inside the next block. I also added comments that in the future we may check more types of objects. > src/hotspot/share/cds/aotOopChecker.cpp line 55: > >> 53: precond(vmClasses::URL_klass()->is_final()); >> 54: >> 55: if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) { > > URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient? Since the `precond` is now inside this block, I can't use `==` anymore. Othewise if we had an instance of a subclass of URL then we will never get into the `if` block. > src/hotspot/share/classfile/javaClasses.cpp line 1063: > >> 1061: >> 1062: // Statically allocate fixup lists because they always get created. >> 1063: void java_lang_Class::allocate_fixup_lists() { > > Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499266 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499303 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499362 From iklam at openjdk.org Wed Sep 10 04:16:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:10 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 16:46:13 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 > > src/hotspot/share/memory/iterator.inline.hpp line 58: > >> 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); >> 57: } else { >> 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); > > Why is the null check and assert not valid anymore? The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions. Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`). After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499472 From fyang at openjdk.org Wed Sep 10 07:35:02 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 10 Sep 2025 07:35:02 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes Just FYI: My local tier1-tier3 tests on linux-riscv64 platform are still good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3273695581 From duke at openjdk.org Wed Sep 10 07:34:58 2025 From: duke at openjdk.org (erifan) Date: Wed, 10 Sep 2025 07:34:58 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v11] In-Reply-To: References: Message-ID: <_ZKvuU_IqxgtXTVqz8yS2XOnItp0mtlemk2CR2p551s=.5c2ce4d5-f851-4acc-9994-adc76813d640@github.com> On Wed, 9 Jul 2025 06:08:33 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request incrementally with one additional commit since the last revision: > > Update the code comment @eme64 Thank you for your patience in reviewing this PR. I'm doing some internal testing and expect to push a new commit next week. I'll be on vacation for the next two days. Thank you! ------------- PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-3204218047 From duke at openjdk.org Wed Sep 10 07:35:03 2025 From: duke at openjdk.org (erifan) Date: Wed, 10 Sep 2025 07:35:03 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v11] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 12:56:40 GMT, Emanuel Peter wrote: >> erifan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the code comment > > src/hotspot/share/opto/vectornode.cpp line 2243: > >> 2241: if (in1->Opcode() != Op_VectorMaskCmp || >> 2242: in1->outcnt() != 1 || >> 2243: !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || > > Suggestion: > > !in1->as_VectorMaskCmp()->predicate_can_be_negated() || > > Brackets are unnecessary, and rather make it harder to read. Good catch, done. > src/hotspot/share/opto/vectornode.cpp line 2277: > >> 2275: res = VectorNode::Ideal(phase, can_reshape); >> 2276: } >> 2277: return res; > > What if someone comes and wants to add yet another optimization before `VectorNode::Ideal`? Your code layout would give us deeper and deeper nesting. I suggest flattening it like this: > Suggestion: > > > Node* res = Ideal_XorV_VectorMaskCmp(phase, can_reshape); > if (res != nullptr) { return res; } > > return VectorNode::Ideal(phase, can_reshape); Make sense, done. > test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 351: > >> 349: public void testCompareULEMaskNotLong() { >> 350: testCompareMaskNotLong(VectorOperators.ULE); >> 351: } > > You could consider making the operator a `@Param` next time. > > There are multiple tricks to do that: > - `test/micro/org/openjdk/bench/vm/compiler/VectorStoreToLoadForwarding.java` using `MethodHandles.constant` > - Some inner class that has a static final, which is initialized from the non-final `@Param` value. > - Probably even `StableValue` would work, but I have not yet experimented with it. > > It would be nice if we could do the same with the primitive types, but that's probably not going to work as easily. > > Really just an idea for next time. Good point, I didn't know about these methods before. I will submit this change in my next commit, thank you. > test/micro/org/openjdk/bench/jdk/incubator/vector/MaskCompareNotBenchmark.java line 366: > >> 364: public void testCompareNEMaskNotFloat() { >> 365: testCompareMaskNotFloat(VectorOperators.NE); >> 366: } > > You could still add the other comparisons as well, so we can see the performance difference. Very optional, feel free to ignore this suggestion. Sounds good, this will be added with the above change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2335413222 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2335421260 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2335825557 PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2335827904 From epeter at openjdk.org Wed Sep 10 07:45:53 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Sep 2025 07:45:53 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v7] In-Reply-To: References: <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com> Message-ID: On Wed, 3 Sep 2025 10:09:58 GMT, erifan wrote: >>> Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function. >> >> I see. Ok. Hmm. I still think that the logic should be in `BoolTest`, because that is where the exact implementation of the enum values is. In that context it is easier to see why `^4` does the negation. And imagine we were ever to change the enum values, then it would be harder to find your code and fix it. >> >> Maybe it could be called `BoolTest::negate_mask(mast btm)` and explain in a comment that both signed and unsigned is supported. > > Hi @eme64 @theRealAph @XiaohongGong @fg1417 @shqking , could you help take a look at this PR, thanks @erifan Sounds good. No rush, it takes as long as it takes. I'll soon be on vacation too and may not respond until mid of October. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-3273732881 From tschatzl at openjdk.org Wed Sep 10 07:56:42 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 07:56:42 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=54 Stats: 7114 lines in 112 files changed: 2590 ins; 3583 del; 941 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 07:56:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 07:56:44 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:47:10 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * sort includes > > We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. > > Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. > > Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) Merged. Thanks for another round of testing (also to @TheRealMDoerr). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3273765120 From tschatzl at openjdk.org Wed Sep 10 08:21:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 08:21:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 07:47:00 GMT, Emanuel Peter wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * sort includes > > test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: > >> 1487: @Test >> 1488: @IR(failOn = IRNode.ALLOC) >> 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail > > Can you explain what led to the difference? Can you also set an upper bound? With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2335959266 From epeter at openjdk.org Wed Sep 10 08:31:57 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Sep 2025 08:31:57 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:19:15 GMT, Thomas Schatzl wrote: >> test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: >> >>> 1487: @Test >>> 1488: @IR(failOn = IRNode.ALLOC) >>> 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail >> >> Can you explain what led to the difference? Can you also set an upper bound? > > With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. Is this going to be GC independent? What if the VM swaps to another GC ergonomically? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2335985122 From chagedorn at openjdk.org Wed Sep 10 08:58:52 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 10 Sep 2025 08:58:52 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:28:26 GMT, Emanuel Peter wrote: >> With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. > > Is this going to be GC independent? What if the VM swaps to another GC ergonomically? The test runs with `vm.flagless`. But I suggest to just go with `>= 1` instead to be on the safe side. The purpose of this IR rule in the context of this test is really just that it does not fail and not about catching real issues/verifying the IR. If we still want to test the improved loop unrolling opportunities, I suggest to create a separate IR test for it, possibly in a separate RFE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336052099 From duke at openjdk.org Wed Sep 10 09:01:06 2025 From: duke at openjdk.org (Johny Jose) Date: Wed, 10 Sep 2025 09:01:06 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v3] In-Reply-To: References: Message-ID: > Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 Johny Jose has updated the pull request incrementally with one additional commit since the last revision: Review changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26815/files - new: https://git.openjdk.org/jdk/pull/26815/files/78d3efbf..7f553cc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26815&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26815&range=01-02 Stats: 8 lines in 2 files changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26815.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26815/head:pull/26815 PR: https://git.openjdk.org/jdk/pull/26815 From amitkumar at openjdk.org Wed Sep 10 09:22:33 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 10 Sep 2025 09:22:33 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). Hi @tschatzl, I see one build failure on s390x, # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 # # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) # Problematic frame: # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (or dumping to /home/amit/jdk/make/core.1801882) I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274080889 From ayang at openjdk.org Wed Sep 10 09:30:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 09:30:52 GMT Subject: RFR: 8367157: Remove jrunscript tool In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> Message-ID: On Tue, 9 Sep 2025 07:18:25 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157. > > `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests. > > tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27163#pullrequestreview-3205293803 From aph at openjdk.org Wed Sep 10 09:36:49 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Sep 2025 09:36:49 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 95: > 93: Label loop; > 94: Label next; > 95: const Register end = count; This aliasing of register names is tricky and confusing. A trap for maintainers, of the kind that people have fallen into already. src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 104: > 102: __ lsr(start, start, CardTable::card_shift()); > 103: __ lsr(end, end, CardTable::card_shift()); > 104: __ sub(count, end, start); // Number of bytes to mark Because `end` is inclusive, `count` here is the number of bytes to mark - 1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336167617 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336164656 From dfuchs at openjdk.org Wed Sep 10 09:44:35 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 10 Sep 2025 09:44:35 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v4] In-Reply-To: <6n_X3OHVCgQf4cn_-wSa43_CNVlkB5tA3b4ylohlb14=.a0d5de68-db13-4661-87b8-fe7e8add0543@github.com> References: <6n_X3OHVCgQf4cn_-wSa43_CNVlkB5tA3b4ylohlb14=.a0d5de68-db13-4661-87b8-fe7e8add0543@github.com> Message-ID: <8jEYWCaT2qx12-tHuC_tCVZUIc3V7hKhfFRx-jC0qfQ=.79dd1338-962b-4891-ab60-cdf75ea03db2@github.com> On Tue, 9 Sep 2025 19:19:22 GMT, David Beaumont wrote: >> The writer field of the handler needs to be re-checked for null inside the locked region before use. > > David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk_8365483/squashed > - License fix. > - Adding test (thanks Jai) > - Re-check writer after locking Still LGTM. Thanks for merging with the latest master changes. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27173#pullrequestreview-3205346381 From duke at openjdk.org Wed Sep 10 10:51:43 2025 From: duke at openjdk.org (duke) Date: Wed, 10 Sep 2025 10:51:43 GMT Subject: RFR: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails [v4] In-Reply-To: <6n_X3OHVCgQf4cn_-wSa43_CNVlkB5tA3b4ylohlb14=.a0d5de68-db13-4661-87b8-fe7e8add0543@github.com> References: <6n_X3OHVCgQf4cn_-wSa43_CNVlkB5tA3b4ylohlb14=.a0d5de68-db13-4661-87b8-fe7e8add0543@github.com> Message-ID: On Tue, 9 Sep 2025 19:19:22 GMT, David Beaumont wrote: >> The writer field of the handler needs to be re-checked for null inside the locked region before use. > > David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk_8365483/squashed > - License fix. > - Adding test (thanks Jai) > - Re-check writer after locking @david-beaumont Your change (at version d174f56d18fb8b506336ed70ec4f42a2afbd11d2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27173#issuecomment-3274398071 From duke at openjdk.org Wed Sep 10 10:58:55 2025 From: duke at openjdk.org (Johny Jose) Date: Wed, 10 Sep 2025 10:58:55 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:01:06 GMT, Johny Jose wrote: >> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes Changes made to add synchronise on the table reference in the getDGCLeaseTableSize method. Reverted back the number of objects left to the initial values. Tested locally with multiple runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26815#issuecomment-3274419892 From duke at openjdk.org Wed Sep 10 10:59:00 2025 From: duke at openjdk.org (Johny Jose) Date: Wed, 10 Sep 2025 10:59:00 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 11:46:17 GMT, Mark Sheppard wrote: >> Johny Jose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8365398 >> - 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently > > test/jdk/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java line 130: > >> 128: /* numLeft should be 6 - if 11 there is a problem. */ >> 129: if (numLeft > 6) { >> 130: TestLibrary.bomb("Too many objects in DGCImpl.leaseTable: "+ > > This doesn't solve the problem, the structure of the test is problematic please c.f. comments in bug Synchronized the code where DGCLeaseTable is read and verified the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26815#discussion_r2336373029 From amitkumar at openjdk.org Wed Sep 10 11:10:00 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 10 Sep 2025 11:10:00 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). > Hi @tschatzl, I see one build failure on s390x, > > ``` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) > # Problematic frame: > # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe > # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (or dumping to /home/amit/jdk/make/core.1801882) > ``` > > I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. Seems like build failure came from one change merged yesterday- https://github.com/openjdk/jdk/pull/26399, I am working on it and created https://bugs.openjdk.org/browse/JDK-8367325 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274462944 From tschatzl at openjdk.org Wed Sep 10 11:31:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:31:24 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). > > Hi @tschatzl, I see one build failure on s390x, > > ``` > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 > > # > > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) > > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) > > # Problematic frame: > > # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe [...] > > > > I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. > > Seems like build failure came from one change merged yesterday- #26399, I am working on it and created https://bugs.openjdk.org/browse/JDK-8367325 This should definitely be caused by that other change. Apologies for the trouble. Thank you for working on this. Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274535127 From tschatzl at openjdk.org Wed Sep 10 11:36:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:36:26 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v56] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - ... and 65 more: https://git.openjdk.org/jdk/compare/edae355e...de1469d6 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=55 Stats: 7114 lines in 112 files changed: 2590 ins; 3583 del; 941 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 11:36:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:36:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 That windows-x64 failure also seems to be an issue caused by another change merged in today :( Already fixed in [JDK-8367309](https://bugs.openjdk.org/browse/JDK-8367309). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274545641 From tschatzl at openjdk.org Wed Sep 10 11:44:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:44:30 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v57] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * aph review, fix some comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/de1469d6..d0ca9062 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=56 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=55-56 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 11:44:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:44:34 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:33:42 GMT, Andrew Haley wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: >> >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * iwalulya: remove confusing comment >> - * sort includes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * improve logging for refinement, making it similar to marking logging >> - * commit merge changes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * fix merge error >> - * forgot to actually save the files >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 > > src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 95: > >> 93: Label loop; >> 94: Label next; >> 95: const Register end = count; > > This aliasing of register names is tricky and confusing. A trap for maintainers, of the kind that people have fallen into already. I can argue I was following precedence :) I see your point though. What do you suggest to do here? Use `count` throughout instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336468727 From duke at openjdk.org Wed Sep 10 11:52:28 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 10 Sep 2025 11:52:28 GMT Subject: Integrated: 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 14:25:00 GMT, David Beaumont wrote: > The writer field of the handler needs to be re-checked for null inside the locked region before use. This pull request has now been integrated. Changeset: 4d4e51c4 Author: David Beaumont Committer: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/4d4e51c41fed79427fb621fd9fcc8e5e23bfb287 Stats: 147 lines in 2 files changed: 142 ins; 2 del; 3 mod 8365483: Test sun/rmi/runtime/Log/6409194/NoConsoleOutput.java sometimes fails Reviewed-by: dfuchs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27173 From iwalulya at openjdk.org Wed Sep 10 12:03:42 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:42 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v57] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 11:44:30 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * aph review, fix some comment Changes requested by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 154: > 152: void assert_state(State expected); > 153: > 154: static void snapshot_heap_into(G1CardTableClaimTable* sweep_table); Any reason why this is static? Don't need to send `_sweep_table` as an argument if it wasn't static. ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3200132750 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336517161 From iwalulya at openjdk.org Wed Sep 10 12:03:47 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:47 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes src/hotspot/share/gc/g1/g1Arguments.cpp line 250: > 248: // Verify that the maximum parallelism isn't too high to eventually overflow > 249: // the refcount in G1CardSetContainer. > 250: uint max_parallel_refinement_threads = G1ConcRefinementThreads; Don't need to local variable `max_parallel_refinement_threads` any more, can use G1ConcRefinementThreads directly. src/hotspot/share/gc/g1/g1CardTableClaimTable.inline.hpp line 95: > 93: i_card++; > 94: } > 95: assert(false, "should have early-returned"); maybe use `ShouldNotReachHere();` src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 216: > 214: class G1SwapThreadCardTableClosure : public HandshakeClosure { > 215: public: > 216: G1SwapThreadCardTableClosure() : HandshakeClosure("G1 Swap JT card table") { } Above on L206 we use "Refine Java Thread CT", here we use "Swap JT card table" not sure which is better "Java Thread CT" vs. "JT card table", but lets pick one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332539864 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332881834 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2333281435 From iwalulya at openjdk.org Wed Sep 10 12:03:51 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:51 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp line 43: > 41: // Claiming works on full region (all cards in region) or a range of contiguous cards > 42: // (chunk). Chunk size is given at construction time. > 43: class G1CardTableClaimTable : public CHeapObj { Do we need the `Table` in the `G1CardTableClaimTable` or can just calling it `G1CardTableClaimer` suffice? src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 301: > 299: // Indicate that last refinement adjustment had been deferred due to not > 300: // obtaining the heap lock. > 301: bool wait_for_heap_lock() const { return _heap_was_locked; } `wait_for_heap_lock()` does not do any waiting, maybe just maintain `heap_was_locked` as the method name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336340738 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336332933 From tschatzl at openjdk.org Wed Sep 10 12:21:33 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 12:21:33 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:44:20 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: >> >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * iwalulya: remove confusing comment >> - * sort includes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * improve logging for refinement, making it similar to marking logging >> - * commit merge changes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * fix merge error >> - * forgot to actually save the files >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 > > src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp line 43: > >> 41: // Claiming works on full region (all cards in region) or a range of contiguous cards >> 42: // (chunk). Chunk size is given at construction time. >> 43: class G1CardTableClaimTable : public CHeapObj { > > Do we need the `Table` in the `G1CardTableClaimTable` or can just calling it `G1CardTableClaimer` suffice? This is the table the claimer below works on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336568870 From ihse at openjdk.org Wed Sep 10 12:31:20 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 10 Sep 2025 12:31:20 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. > > As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run. @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3274738832 From tschatzl at openjdk.org Wed Sep 10 12:40:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 12:40:11 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v58] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review * tried to remove "logged card" terminology for the current "pending card" one ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/d0ca9062..b47c7b01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=57 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=56-57 Stats: 55 lines in 11 files changed: 0 ins; 1 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From konstantin.kletschke at inside-m2m.de Wed Sep 10 12:54:29 2025 From: konstantin.kletschke at inside-m2m.de (Konstantin Kletschke) Date: Wed, 10 Sep 2025 14:54:29 +0200 Subject: Java crashes using musl-1.2.5 Message-ID: Hello, I am used to crosscompile openjdk for cortex-a[7|8|9] manually or using buildroot framework without severe Problems. ARM EABIhf 32Bit. However recently I got in contact with a customer's rootfs using musl-1.2.5 instead of musl-1.2.4 which I was used to and had no problems with. Severe debugging resulted in the crash whenever musl-1.2.5 was used in the target (regardeless what musl version was used to crosscompile and regardeless with java I tried, correto-24, openjdk-21, openjdk-24). I tested with a helloworld downloaded from github somewhere. "java -jar helloworld.jar" crashes. Unzippping the jar and using "java -cp . HelloWorld" works! Crashes looks something like those: # SIGSEGV (0xb) at pc=0x7693e018, pid=8026, tid=8027 # # JRE version: OpenJDK Runtime Environment (21.0+21) (build 21+21) # Java VM: OpenJDK Server VM (21+21, mixed mode, serial gc, linux-arm) # Problematic frame: # V [libjvm.so+0x61e018] FATAL ERROR in native method: Null object passed to JNI at sun.nio.fs.UnixNativeDispatcher.stat0(java.base at 21/Native Method) at sun.nio.fs.UnixNativeDispatcher.stat(java.base at 21/Unknown Source) at sun.nio.fs.UnixFileAttributes.get(java.base at 21/Unknown Source) at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(java.base at 21/Unknown Source) at sun.nio.fs.UnixFileSystemProvider.readAttributes(java.base at 21/Unknown Source) at sun.nio.fs.LinuxFileSystemProvider.readAttributes(java.base at 21/Unknown Source) at java.nio.file.Files.readAttributes(java.base at 21/Unknown Source) at java.util.zip.ZipFile$Source.get(java.base at 21/Unknown Source) at java.util.zip.ZipFile$CleanableResource.(java.base at 21/Unknown Source) at java.util.zip.ZipFile.(java.base at 21/Unknown Source) at java.util.zip.ZipFile.(java.base at 21/Unknown Source) at java.util.jar.JarFile.(java.base at 21/Unknown Source) at java.util.jar.JarFile.(java.base at 21/Unknown Source) at java.util.jar.JarFile.(java.base at 21/Unknown Source) at sun.launcher.LauncherHelper.getMainClassFromJar(java.base at 21/Unknown Source) at sun.launcher.LauncherHelper.loadMainClass(java.base at 21/Unknown Source) at sun.launcher.LauncherHelper.checkAndLoadMain(java.base at 21/Unknown Source) Aborted With 1.2.4 everything works fine. Farther debugging revealed that following fix in Java allowed to run it with 1.2.5: Index: openjdk-21.0.9+6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c =================================================================== --- openjdk-21.0.9+6.orig/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c +++ openjdk-21.0.9+6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c @@ -430,7 +430,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_ini capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_BIRTHTIME; #endif #if defined(__linux__) - my_statx_func = (statx_func*) dlsym(RTLD_DEFAULT, "statx"); + my_statx_func = NULL; if (my_statx_func != NULL) { capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_BIRTHTIME; } May be this has something to do with the stat ./. stat64 stuff changed in musl from 1.2.4 to 1.2.5 or so. I already headed to the musl people but I am not shure if its placed better over there or here. I also already showed up at client-libs-dev but was told to be come over here. Kind Regards Konstantin -- INSIDE M2M GmbH Konstantin Kletschke Berenbosteler Stra?e 76 B 30823 Garbsen Telefon: +49 (0) 5137 90950136 Mobil: +49 (0) 151 15256238 Fax: +49 (0) 5137 9095010 konstantin.kletschke at inside-m2m.de http://www.inside-m2m.de Gesch?ftsf?hrung: Michael Emmert, Derek Uhlig HRB: 111204, AG Hannover From epeter at openjdk.org Wed Sep 10 12:55:29 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Sep 2025 12:55:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:53:13 GMT, Christian Hagedorn wrote: >> Is this going to be GC independent? What if the VM swaps to another GC ergonomically? > > The test runs with `vm.flagless`. But I suggest to just go with `>= 1` instead to be on the safe side. The purpose of this IR rule in the context of this test is really just that it does not fail and not about catching real issues/verifying the IR. > > If we still want to test the improved loop unrolling opportunities, I suggest to create a separate IR test for it, possibly in a separate RFE. I suppose that's probably not possible, as far as I know we always run with G1GC, so it should be fine :) We could put an upper bound of 3, maybe 4 here though. Just see what passes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336663260 From ihse at openjdk.org Wed Sep 10 13:16:30 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 10 Sep 2025 13:16:30 GMT Subject: RFR: 8367157: Remove jrunscript tool In-Reply-To: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> References: <6FohJuKpwbdnPdM8vU1FXcCrsZV1iaHB4I5ClE08qc8=.e59c8229-080d-49d5-a490-99cc736389f2@github.com> Message-ID: On Tue, 9 Sep 2025 07:18:25 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes the `jrunscript` tool? This addresses https://bugs.openjdk.org/browse/JDK-8367157. > > `jrunscript` is an experimental and unsupported tool which was deprecated for removal in Java 24. The commits in this PR remove the tool, its man pages and any references to it in the tests. > > tier1 through tier8 have been run with this change in the CI and no related failures have been found. I'll file a CSR for this change and also add a release note. Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27163#pullrequestreview-3206106586 From duke at openjdk.org Wed Sep 10 14:03:51 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 10 Sep 2025 14:03:51 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList In-Reply-To: References: <0sMXM6BEv8KDpmDQs0BU4w9CWkcXAXX0mNY07fyMax4=.371452de-f5ee-4725-be95-b9b38981a6f5@github.com> Message-ID: On Fri, 5 Sep 2025 14:56:25 GMT, Raffaello Giulietti wrote: > Would you like me to reconsider their removals in my [draft PR](https://github.com/openjdk/jdk/pull/26990)? Yes, please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3258817438 From rgiulietti at openjdk.org Wed Sep 10 14:03:50 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 10 Sep 2025 14:03:50 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList In-Reply-To: <0sMXM6BEv8KDpmDQs0BU4w9CWkcXAXX0mNY07fyMax4=.371452de-f5ee-4725-be95-b9b38981a6f5@github.com> References: <0sMXM6BEv8KDpmDQs0BU4w9CWkcXAXX0mNY07fyMax4=.371452de-f5ee-4725-be95-b9b38981a6f5@github.com> Message-ID: On Fri, 5 Sep 2025 14:37:01 GMT, Johannes Graham wrote: >> When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. >> >> This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. > > @rgiulietti This requires the use of the `getDigits` and `getDecimalExponent` methods in `FloatingDecimal`, which are proposed to be removed in https://github.com/openjdk/jdk/pull/26990 @j3graham Yes, they are proposed to be removed since they are currently useless. Would you like me to reconsider their removals in my [draft PR](https://github.com/openjdk/jdk/pull/26990)? > Benchmark results Aarch64 M4 > > > Benchmark Mode Cnt Score Error Units > -DefFormatterBench.testDefNumberFormatter thrpt 15 15612.853 ? 448.025 ops/ms > -DefFormatterBench.testLargeBigDecDefNumberFormatter thrpt 15 4075.254 ? 58.170 ops/ms > -DefFormatterBench.testSmallBigDecDefNumberFormatter thrpt 15 12467.137 ? 194.961 ops/ms > +DefFormatterBench.testDefNumberFormatter thrpt 15 19196.464 ? 475.871 ops/ms +26% > +DefFormatterBench.testLargeBigDecDefNumberFormatter thrpt 15 4981.756 ? 82.088 ops/ms +22% > +DefFormatterBench.testSmallBigDecDefNumberFormatter thrpt 15 15936.774 ? 108.450 ops/ms +28% > Finished running test 'micro:DefFormatterBench' > > > This includes adding a fast-path in BigInteger.toString to help extract significant digits from a BigDecimal without a slowdown. @j3graham [JDK-8367324](https://bugs.openjdk.org/browse/JDK-8367324) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3258648900 PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3274449176 From duke at openjdk.org Wed Sep 10 14:03:49 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 10 Sep 2025 14:03:49 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList Message-ID: When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. ------------- Commit messages: - unneeded comment - extract fitsIntoLong method, cleanup test - Merge branch 'openjdk:master' into digitlist-double4 - remove unused import - add fast path in BigInteger.toString for values that fit into a long - add benchmark for BigDecimal formatting - avoid parsing Changes: https://git.openjdk.org/jdk/pull/27118/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27118&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367324 Stats: 140 lines in 5 files changed: 51 ins; 72 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27118.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27118/head:pull/27118 PR: https://git.openjdk.org/jdk/pull/27118 From duke at openjdk.org Wed Sep 10 14:03:50 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 10 Sep 2025 14:03:50 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList In-Reply-To: References: Message-ID: <0sMXM6BEv8KDpmDQs0BU4w9CWkcXAXX0mNY07fyMax4=.371452de-f5ee-4725-be95-b9b38981a6f5@github.com> On Fri, 5 Sep 2025 14:18:19 GMT, Johannes Graham wrote: > When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. > > This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. @rgiulietti This requires the use of the `getDigits` and `getDecimalExponent` methods in `FloatingDecimal`, which are proposed to be removed in https://github.com/openjdk/jdk/pull/26990 Benchmark results Aarch64 M4 Benchmark Mode Cnt Score Error Units -DefFormatterBench.testDefNumberFormatter thrpt 15 15612.853 ? 448.025 ops/ms -DefFormatterBench.testLargeBigDecDefNumberFormatter thrpt 15 4075.254 ? 58.170 ops/ms -DefFormatterBench.testSmallBigDecDefNumberFormatter thrpt 15 12467.137 ? 194.961 ops/ms +DefFormatterBench.testDefNumberFormatter thrpt 15 19196.464 ? 475.871 ops/ms +26% +DefFormatterBench.testLargeBigDecDefNumberFormatter thrpt 15 4981.756 ? 82.088 ops/ms +22% +DefFormatterBench.testSmallBigDecDefNumberFormatter thrpt 15 15936.774 ? 108.450 ops/ms +28% Finished running test 'micro:DefFormatterBench' This includes adding a fast-path in BigInteger.toString to help extract significant digits from a BigDecimal without a slowdown. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3258587899 PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3267017431 From rgiulietti at openjdk.org Wed Sep 10 14:03:52 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 10 Sep 2025 14:03:52 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList In-Reply-To: References: Message-ID: <5Ku3CBKFjTsVdN6wUbJE7DnD-Bbr-zxLUWDyi0rS_io=.ffc6e6fc-abcc-47ef-8d77-2689fd894d3e@github.com> On Fri, 5 Sep 2025 14:18:19 GMT, Johannes Graham wrote: > When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. > > This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. Please go ahead with your PR, regardless of mine. I'll reintroduce the removed code with the next commit, sometimes next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3259150834 From asmehra at openjdk.org Wed Sep 10 14:22:44 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:22:44 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 04:12:04 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1063: >> >>> 1061: >>> 1062: // Statically allocate fixup lists because they always get created. >>> 1063: void java_lang_Class::allocate_fixup_lists() { >> >> Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? > > I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? I was referring to `fixup_module_field_list`, but the comments are for `fixup_mirror_list`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2336936776 From jiangli at openjdk.org Wed Sep 10 14:46:58 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 Sep 2025 14:46:58 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. > > As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run. > @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this. @magicus I'll take a look today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3275307649 From asmehra at openjdk.org Wed Sep 10 14:52:31 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:52:31 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> References: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> Message-ID: On Wed, 10 Sep 2025 04:16:03 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @ashu-mehra review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > - @DanHeidinga comments > - tightened SystemDictionary::preload_class() > - Fixed bugs found in JCK > - added entry in ProblemList-AotJdk.txt due to 8323727 > - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 src/hotspot/share/cds/filemap.cpp line 1861: > 1859: const char* archive_type = CDSConfig::type_of_archive_being_loaded(); > 1860: CDSConfig::set_has_aot_linked_classes(true); > 1861: if (is_static()) { `CDSConfig` is a global configuration, not specific to static or dynamic archive, and IIUC it is not possible to just load a dynamic archive, without loading a static archive. So it seems `is_static()` check is redundant here. Continuing with this line of thought, it seems if `has_aot_linked_classes` is true then `is_using_preloaded_classes` will also be true. Then why do we even need this additional flag to indicate preloading of classes? This is going to be the default behavior when `has_aot_linked_classes` is true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337020552 From asmehra at openjdk.org Wed Sep 10 14:52:33 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:52:33 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 04:12:08 GMT, Ioi Lam wrote: >> src/hotspot/share/memory/iterator.inline.hpp line 58: >> >>> 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); >>> 57: } else { >>> 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); >> >> Why is the null check and assert not valid anymore? > > The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions. > > Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`). > > After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore. That makes `is_pending_aot_linked_class` dead code. Can it be removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337025501 From iwalulya at openjdk.org Wed Sep 10 14:54:29 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 14:54:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v58] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 12:40:11 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review > * tried to remove "logged card" terminology for the current "pending card" one src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp line 36: > 34: class G1ConcurrentRefine; > 35: > 36: // Concurrent refinement control thread watching card mark accrual on the card Suggestion: // Concurrent refinement control thread watching card mark accrual on the card table src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp line 182: > 180: double _cur_optional_merge_heap_roots_time_ms; > 181: // Included in above merge and optional-merge time. > 182: double _cur_distribute_log_buffers_time_ms; No longer used. src/hotspot/share/gc/g1/g1HeapRegion.hpp line 41: > 39: class G1CardSet; > 40: class G1CardSetConfiguration; > 41: class G1CardTable; Do we need the Forward declaration here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336962845 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336992289 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2337004685 From dfuchs at openjdk.org Wed Sep 10 15:21:47 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 10 Sep 2025 15:21:47 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v4] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 08:11:15 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? >> >> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. >> >> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. >> >> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - remove format() call in exception message creation > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - add test > - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed test/jdk/javax/naming/ldap/LdapClientConnTest.java line 62: > 60: * @library /test/lib > 61: * @build jdk.test.lib.net.URIBuilder > 62: * @run junit LdapClientConnTest Since this test creates a daemon thread and does not try to join the thread at the end it might be more prudent to run it in `/othervm` mode? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2337112834 From tschatzl at openjdk.org Wed Sep 10 15:28:39 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 15:28:39 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/b47c7b01..c469c137 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=58 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=57-58 Stats: 9 lines in 3 files changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From dfuchs at openjdk.org Wed Sep 10 18:08:20 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 10 Sep 2025 18:08:20 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 656 commits: - merge latest changes from master branch - modify http3 test timeouts - qpack - take knownReceivedCount into account during DT entries eviction - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - Simplify control flow - Remove unnecessary instanceof checks - Use IntFunction for header generator - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=16 Stats: 105844 lines in 474 files changed: 103013 ins; 1333 del; 1498 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From iklam at openjdk.org Wed Sep 10 18:30:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 18:30:57 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> Message-ID: On Wed, 10 Sep 2025 14:47:19 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 > > src/hotspot/share/cds/filemap.cpp line 1861: > >> 1859: const char* archive_type = CDSConfig::type_of_archive_being_loaded(); >> 1860: CDSConfig::set_has_aot_linked_classes(true); >> 1861: if (is_static()) { > > `CDSConfig` is a global configuration, not specific to static or dynamic archive, and IIUC it is not possible to just load a dynamic archive, without loading a static archive. So it seems `is_static()` check is redundant here. > Continuing with this line of thought, it seems if `has_aot_linked_classes` is true then `is_using_preloaded_classes` will also be true. Then why do we even need this additional flag to indicate preloading of classes? This is going to be the default behavior when `has_aot_linked_classes` is true. There is actually a tricky situation -- static archive doesn't have `-XX:+AOTClassLinking` but the dynamic archive was created with `-XX:+AOTClassLinking`. I have created [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366) to remove support for `-XX:+AOTClassLinking` for the dynamic archive. If that gets reviewed and integrated, then I will update this PR to remove `is_using_preloaded_classes()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337574998 From iklam at openjdk.org Wed Sep 10 18:30:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 18:30:58 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:19:33 GMT, Ashutosh Mehra wrote: >> I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? > > I was referring to `fixup_module_field_list`, but the comments are for `fixup_mirror_list`. It's needed because of `-XX:+AOTClassLinking` in the dynamic archive. I will update this after removing `-XX:+AOTClassLinking` support for the dynamic archive in [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337579397 From davidalayachew at gmail.com Wed Sep 10 19:01:08 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Wed, 10 Sep 2025 15:01:08 -0400 Subject: Can we deprecate Path.endsWith(String)? Message-ID: Hello @core-libs-dev , I have frequently run into the following pothole. Imagine the following directory setup. root/folderA/fileX.java root/folderB/fileY.js root/folderC/fileZ.html In this directory, let's say that we run the following code. Files .walk(Path.of("root")) .filter(path -> path.endsWith("html")) .forEach(System.out::println) ; One would expect only fileZ.html to be printed out, but nothing does. The reason why is because path.endsWith(String) is effectively an alias for path.endsWith(Path.of(String)). The confusion being that Path.of(someString) is looking for a file or a directory. Thus, since there is neither a file nor a folder called "html", the stream prints out nothing. This a very easy pothole to fall into, as the method name endsWith is the same as the one for String, thus, people will easily mix it up. And worse yet, depending on what they test with, they can easily confuse themselves into thinking they are good. For example, if I had done "fileZ.html" as my endsWith, I would have returned exactly what was expected, causing me to be misled. And as a cherry on the top, the syntactic benefit of this method is very little. Wrapping your string in a Path.of() means that you fall under the Path.endsWith(Path) overload, which is more explicit what it does. And at the very least, should give pause to the developer thinking it is doing String comparison, as they have to wrap their String in a Path, causing a moment to think. So, since this is a low value method and it causes high confusion, I vote that we deprecate it. Thoughts? Thank you for your time. David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarrell at openjdk.org Wed Sep 10 19:46:12 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 10 Sep 2025 19:46:12 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v14] In-Reply-To: References: Message-ID: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: update method name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/be7dea7a..1d8cd4d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=12-13 Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From kfarrell at openjdk.org Wed Sep 10 20:00:31 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 10 Sep 2025 20:00:31 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v13] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 21:17:32 GMT, Roger Riggs wrote: >> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: >> >> update note to @api note > > test/jdk/java/util/UUID/UUIDTest.java line 52: > >> 50: unixEpochTimeMillisTest(); >> 51: unixEpochTimeMillisTest_Multi(); >> 52: unixEpochTimeMillis_userInputTest(); > > Also rename the tests to use the `epochMillis` naming. Thanks Roger, I have updated the name accordingly. WRT updating the implementation to use nextLong(), since we are no longer using the higher percision bits in the first half of the UUID, we are using random bits in their place, so we would need to call `nextLong` twice and overwrite with the timestamp etc. if I understand correctly. From what ive seen in the microbenchmarks, this results in a large perfomance dec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2337765286 From brian.burkhalter at oracle.com Wed Sep 10 20:07:47 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Sep 2025 20:07:47 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: Message-ID: Hello David, Redirecting to nio-dev. On Sep 10, 2025, at 12:01?PM, David Alayachew wrote: One would expect only fileZ.html to be printed out, but nothing does. The reason why is because path.endsWith(String) is effectively an alias for path.endsWith(Path.of(String)). The confusion being that Path.of(someString) is looking for a file or a directory. Thus, since there is neither a file nor a folder called "html", the stream prints out nothing. The specification looks like it is pretty clear about the behavior, especially the implementation note in Path.endsWith(String): "The default implementation is equivalent for this path to: endsWith(getFileSystem().getPath(other));" What you were expecting sounds like what would be given by .filter(path -> path.toString().endsWith("html?)) or better .filter(path -> path.getFileName().toString().endsWith("html?)) Is that correct? If we could eventually agree on how to handle file extensions, that would help here. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Wed Sep 10 20:28:07 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Wed, 10 Sep 2025 16:28:07 -0400 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: Message-ID: Hello @brian.burkhalter at oracle.com , Yes exactly. And I'm not trying to say that the method is underspecified -- the javadoc is fairly clear. I'm merely saying that this overload adds little value, while being a tripping hazard for those thinking the name describes the obvious. So, I'd like to deprecate the overload. Those who want the overload, just use the suggestion in the javadocs. On Wed, Sep 10, 2025, 4:07?PM Brian Burkhalter wrote: > Hello David, > > Redirecting to nio-dev. > > On Sep 10, 2025, at 12:01?PM, David Alayachew > wrote: > > One would expect only fileZ.html to be printed out, but nothing does. The > reason why is because path.endsWith(String) is effectively an alias for > path.endsWith(Path.of(String)). The confusion being that > Path.of(someString) is looking for a file or a directory. Thus, since there > is neither a file nor a folder called "html", the stream prints out nothing. > > > The specification looks like it is pretty clear about the behavior, > especially the implementation note in Path.endsWith(String) > > : > > "The default implementation is equivalent for this path to: > > endsWith(getFileSystem().getPath(other));" > > What you were expecting sounds like what would be given by > > .filter(path -> path.toString().endsWith("html?)) > > or better > > .filter(path -> path.getFileName().toString().endsWith("html?)) > > Is that correct? > > If we could eventually agree on how to handle file extensions, that would help here. > > Brian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Sep 10 20:38:48 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Sep 2025 20:38:48 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: Message-ID: <9F189EDF-86E9-45FA-8F6B-727123D223A0@oracle.com> Hello David, On Sep 10, 2025, at 1:28?PM, David Alayachew wrote: Yes exactly. And I'm not trying to say that the method is underspecified -- the javadoc is fairly clear. I'm merely saying that this overload adds little value, while being a tripping hazard for those thinking the name describes the obvious. So, I'd like to deprecate the overload. Those who want the overload, just use the suggestion in the javadocs. There are a number of methods in Path which are the same except for String- vs. Path-valued parameters. I?m not sure we?d want to deprecate just this one although I do see your point. Perhaps some additional disambiguating verbiage in the endsWith(String) specification would help? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Wed Sep 10 21:10:15 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 10 Sep 2025 21:10:15 GMT Subject: RFR: 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c Message-ID: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c:306 Minor cleanup of a missing check for exception pending. ------------- Commit messages: - 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c:306 Changes: https://git.openjdk.org/jdk/pull/27202/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367138 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27202/head:pull/27202 PR: https://git.openjdk.org/jdk/pull/27202 From davidalayachew at gmail.com Wed Sep 10 21:33:48 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Wed, 10 Sep 2025 17:33:48 -0400 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <9F189EDF-86E9-45FA-8F6B-727123D223A0@oracle.com> References: <9F189EDF-86E9-45FA-8F6B-727123D223A0@oracle.com> Message-ID: Oh yes, agreed -- if we were going to do this, can't just be this method. So there is the startsWith method, for example. If we are going down the documentation route, then I'd like a simple example added to the javadocs for both startsWith and endsWith that show what this would and would not match. Not only will this clear up my ambiguity, but there might be a few corners of this api worth showing by example. For example, I had a root path specified by Path.of("."), and when I tried to use the string overload of starts with (the way it was intended to be used), it actually failed because I failed to add the ./ at the front. If we don't want to add this stuff, that's fine. The dev will figure it out eventually. I just keep falling into this hole, so I figured this would make a useful experience report. And if nothing else, then this will help for designing future api's. Thanks for the help. David Alayachew On Wed, Sep 10, 2025, 4:39?PM Brian Burkhalter wrote: > Hello David, > > On Sep 10, 2025, at 1:28?PM, David Alayachew > wrote: > > Yes exactly. > > And I'm not trying to say that the method is underspecified -- the javadoc > is fairly clear. > > I'm merely saying that this overload adds little value, while being a > tripping hazard for those thinking the name describes the obvious. > > So, I'd like to deprecate the overload. Those who want the overload, just > use the suggestion in the javadocs. > > > There are a number of methods in Path which are the same except for > String- vs. Path-valued parameters. I?m not sure we?d want to deprecate > just this one although I do see your point. Perhaps some additional > disambiguating verbiage in the endsWith(String) specification would help? > > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Sep 10 21:58:25 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 10 Sep 2025 21:58:25 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint Message-ID: Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. In particular: 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. Thus two new methods are added to resolve these cases: * findResourceNode(module, path) * containsResource(module, path) Their API takes module and path separately so as to not be confusable with findNode(nodename). However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. ------------- Commit messages: - Add more performant methods for SystemModuleReader Changes: https://git.openjdk.org/jdk/pull/27203/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367005 Stats: 134 lines in 3 files changed: 118 ins; 10 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From bpb at openjdk.org Wed Sep 10 22:02:58 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Sep 2025 22:02:58 GMT Subject: RFR: 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 21:03:32 GMT, Roger Riggs wrote: > JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c:306 > Minor cleanup of a missing check for exception pending. Looks all right. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27202#pullrequestreview-3207968592 From duke at openjdk.org Wed Sep 10 22:05:26 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 10 Sep 2025 22:05:26 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: References: Message-ID: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Found additional place where new API can be used. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/44e07ee0..2cdb1b22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From jlu at openjdk.org Wed Sep 10 22:20:07 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 10 Sep 2025 22:20:07 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 14:18:19 GMT, Johannes Graham wrote: > When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. > > This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. On a first pass, the changes in `DigitList` look good to me: we utilize the `BigDecimal` to retrieve the exponent + unscaled value so that we don't need to re-parse the String representation to determine `decimalAt` and inflate `digits`. Thanks for this improvement which also simplifies and cleans up the code as well. I left some minor comments. src/java.base/share/classes/java/math/BigInteger.java line 4184: > 4182: > 4183: if (fitsIntoLong()) { > 4184: return Long.toString(longValue(), radix); We may want to consider separating this `BigInteger` fast path from this PR/change, since it is independent of the speedup in the `DigitList` changes. Others may not have a problem with it though, so maybe we can wait and see what they say. test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 1: > 1: /* I know the JBS issue was not yet created when the PR was up, but now the Jtreg header needs 8367324 added to bug section. test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 1: > 1: /* Nit: Copyright year bump. test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 88: > 86: > 87: // This will create "small" BigDecimals where unscaled value fits in a long. > 88: BigDecimal bd = BigDecimal.valueOf(value); Can we separate the creation of the BD from the benchmark here and create these values in setup as well. test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 100: > 98: // of the toString value if the BigDecimal instance was reused. > 99: > 100: BigDecimal bd = new BigDecimal(value.unscaledValue(), value.scale()); If we use `@Setup(Level.Iteration)` on setup, I believe we can ensure a fresh `bdValues` for each benchmark iteration measurement. Then we can remove the BD recreation to not be included within the benchmark results which should give us more accurate results. ------------- PR Review: https://git.openjdk.org/jdk/pull/27118#pullrequestreview-3207801811 PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2337937683 PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2337894410 PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2337894989 PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2337905594 PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2337914280 From naoto at openjdk.org Wed Sep 10 22:22:36 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 10 Sep 2025 22:22:36 GMT Subject: RFR: 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 21:03:32 GMT, Roger Riggs wrote: > JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c:306 > Minor cleanup of a missing check for exception pending. +1 ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27202#pullrequestreview-3208003978 From duke at openjdk.org Wed Sep 10 23:47:48 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 10 Sep 2025 23:47:48 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v2] In-Reply-To: References: Message-ID: <4o0n8l-Z-L0aNi6L6UIhrOzNEUscfSjMPryqjvRydfk=.8fb366e0-4081-4d4d-a0a9-fc1e70e86617@github.com> On Wed, 10 Sep 2025 21:06:53 GMT, Justin Lu wrote: >> Johannes Graham has updated the pull request incrementally with two additional commits since the last revision: >> >> - use Level.Invocation >> - review fixes > > test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 100: > >> 98: // of the toString value if the BigDecimal instance was reused. >> 99: >> 100: BigDecimal bd = new BigDecimal(value.unscaledValue(), value.scale()); > > If we use `@Setup(Level.Iteration)` on setup, I believe we can ensure a fresh `bdValues` for each benchmark iteration measurement. Then we can remove the BD recreation to not be included within the benchmark results which should give us more accurate results. Looks like `Level.Invocation` is the one I want. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2338174523 From duke at openjdk.org Wed Sep 10 23:47:47 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 10 Sep 2025 23:47:47 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v2] In-Reply-To: References: Message-ID: <_ZwF0CJ0mY-x-ie19mhkUiTnLlBlDBG6-zCzKaLfbyU=.e8f9d819-d67b-4b31-b19c-3369c69da5ef@github.com> > When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. > > This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. Johannes Graham has updated the pull request incrementally with two additional commits since the last revision: - use Level.Invocation - review fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27118/files - new: https://git.openjdk.org/jdk/pull/27118/files/1475d3aa..6865fe6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27118&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27118&range=00-01 Stats: 24 lines in 2 files changed: 5 ins; 10 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27118.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27118/head:pull/27118 PR: https://git.openjdk.org/jdk/pull/27118 From duke at openjdk.org Wed Sep 10 23:57:21 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 10 Sep 2025 23:57:21 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v2] In-Reply-To: References: Message-ID: <9fwe7YcFQM19gM4JMrH92REwpKxbdVjChQGZdkgjPk8=.3fc0b5d0-7248-4fc8-8a47-7ad692073076@github.com> On Wed, 10 Sep 2025 21:19:32 GMT, Justin Lu wrote: >> Johannes Graham has updated the pull request incrementally with two additional commits since the last revision: >> >> - use Level.Invocation >> - review fixes > > src/java.base/share/classes/java/math/BigInteger.java line 4184: > >> 4182: >> 4183: if (fitsIntoLong()) { >> 4184: return Long.toString(longValue(), radix); > > We may want to consider separating this `BigInteger` fast path from this PR/change, since it is independent of the speedup in the `DigitList` changes. Others may not have a problem with it though, so maybe we can wait and see what they say. Without the fast-path, there was a performance drop with the "small" BigDecimals (from memory about 10%). That's what drove me to tinker with `BigInteger.toString`. But if this one can stand on its own, despite the perf drop, I'm happy to separate out the BigInteger part. I'll generate some new perf numbers after the Level.Invocation fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2338186267 From redestad at openjdk.org Thu Sep 11 00:00:12 2025 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 11 Sep 2025 00:00:12 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> Message-ID: On Wed, 10 Sep 2025 22:05:26 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Found additional place where new API can be used. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 379: > 377: // exist, so it skips checking the nodes cache and only checks for > 378: // an ImageLocation. > 379: if (moduleName.contains("/") || resourcePath.startsWith("/")) { The fast-path guard here and above might improve if they were done before synchronizing, e.g. dropping the modifier and putting a `synchonized (this)` block around the rest of the method. Putting the likely cheaper `resourcePath.startsWith` first might be a small win, too, depending on input/benchmark. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2338193115 From jiangli at openjdk.org Thu Sep 11 00:19:22 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 11 Sep 2025 00:19:22 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v6] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 13:15:57 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Update based on review src/java.base/share/native/launcher/main.c line 41: > 39: > 40: // This is reported when requesting a full version > 41: static char* launcher = LAUNCHER_NAME; Is it guaranteed that `LAUNCHER_NAME` is always defined at build time? Is it safer to keep the `ifdef LAUNCHER_NAME` check and initialize `launcer` to `NULL` if `LAUNCHER_NAME` is not defined? From removed defines.h: #ifdef LAUNCHER_NAME static const char* const_launcher = LAUNCHER_NAME; #else /* LAUNCHER_NAME */ static char* const_launcher = NULL; #endif /* LAUNCHER_NAME */ src/java.base/share/native/launcher/main.c line 44: > 42: > 43: // This is used as the name of the executable in the help message > 44: static char* progname = PROGNAME; Same question for `PROGNAME` as the one for `LAUNCHER_NAME` above. src/java.base/share/native/launcher/main.c line 61: > 59: cpwildcard = JNI_FALSE; > 60: } > 61: if (strncmp(arg, "-J-DjavaLauncherProgname=", 26) == 0) { It's better to replace the hardcoded string length with `strlen()` or `JLI_StrLen()`, e.g.: const char *progname_prefix = "-J-DjavaLauncherProgname="; int progname_prefix_len = strlen(progname_prefix); if (strncmp(arg, "-J-DjavaLauncherProgname=", progname_prefix_len) == 0) { progname = arg + progname_prefix_len; ... src/java.base/windows/native/launcher/relauncher.c line 1: > 1: /* How did you test the relauncher for Windows? Can you remind me if static JDK is support for Windows? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2338153342 PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2338163122 PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2338170678 PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2338210218 From duke at openjdk.org Thu Sep 11 00:36:20 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 00:36:20 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> Message-ID: On Wed, 10 Sep 2025 23:57:36 GMT, Claes Redestad wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Found additional place where new API can be used. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 379: > >> 377: // exist, so it skips checking the nodes cache and only checks for >> 378: // an ImageLocation. >> 379: if (moduleName.contains("/") || resourcePath.startsWith("/")) { > > The fast-path guard here and above might improve if they were done before synchronizing, e.g. dropping the modifier and putting a `synchonized (this)` block around the rest of the method. > > Putting the likely cheaper `resourcePath.startsWith` first might be a small win, too, depending on input/benchmark. When called from SystemModuleFinders this really should never happen (arguably it's IAE) so it won't make a difference per-call if it's changed, and it won't really help reduce the time of the locked section. Both checks will basically always be done, so ordering isn't an issue (but a fair point to raise). Module names are typically short, so while a string scan is not ideal, it's not awful (and we do string concatentaion later anyway). Ideally there would be a ModuleName type to use as the parameter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2338229587 From jiangli at openjdk.org Thu Sep 11 00:43:17 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 11 Sep 2025 00:43:17 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 12:28:43 GMT, Magnus Ihse Bursie wrote: >> Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. >> >> As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run. > > @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this. > @magicus I'll take a look today. Hi @magicus I looked at your changes and focused on the launcher changes. I only looked quickly of the build changes, I think @erikj79's review is sufficient. For launcher changes, my main question is Windows platform support (for static JDK) and testing. The rest of the comments are minor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3276985687 From david.holmes at oracle.com Thu Sep 11 00:59:17 2025 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Sep 2025 10:59:17 +1000 Subject: Java crashes using musl-1.2.5 In-Reply-To: References: Message-ID: <1e8bae95-8a6c-4422-a77f-315bbe7198da@oracle.com> Hi, At present we don't really expect statx to work on Musl-C IIUC the code correctly, but Musl-C 1.2.5 has added it: > This release adds extension functions statx so likely our code needs adjusting to match what is now provided. David On 10/09/2025 10:54 pm, Konstantin Kletschke wrote: > Hello, > > I am used to crosscompile openjdk for cortex-a[7|8|9] manually or using > buildroot framework without severe Problems. > ARM EABIhf 32Bit. > > However recently I got in contact with a customer's rootfs using > musl-1.2.5 instead of musl-1.2.4 which I was used to and had no problems with. > > Severe debugging resulted in the crash whenever musl-1.2.5 was used in > the target (regardeless what musl version was used to crosscompile and > regardeless with java I tried, correto-24, openjdk-21, openjdk-24). > > I tested with a helloworld downloaded from github somewhere. > "java -jar helloworld.jar" crashes. Unzippping the jar and using > "java -cp . HelloWorld" works! > > Crashes looks something like those: > > # SIGSEGV (0xb) at pc=0x7693e018, pid=8026, tid=8027 > # > # JRE version: OpenJDK Runtime Environment (21.0+21) (build 21+21) > # Java VM: OpenJDK Server VM (21+21, mixed mode, serial gc, linux-arm) > # Problematic frame: > # V [libjvm.so+0x61e018] > > FATAL ERROR in native method: Null object passed to JNI > at sun.nio.fs.UnixNativeDispatcher.stat0(java.base at 21/Native Method) > at sun.nio.fs.UnixNativeDispatcher.stat(java.base at 21/Unknown Source) > at sun.nio.fs.UnixFileAttributes.get(java.base at 21/Unknown Source) > at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(java.base at 21/Unknown Source) > at sun.nio.fs.UnixFileSystemProvider.readAttributes(java.base at 21/Unknown Source) > at sun.nio.fs.LinuxFileSystemProvider.readAttributes(java.base at 21/Unknown Source) > at java.nio.file.Files.readAttributes(java.base at 21/Unknown Source) > at java.util.zip.ZipFile$Source.get(java.base at 21/Unknown Source) > at java.util.zip.ZipFile$CleanableResource.(java.base at 21/Unknown Source) > at java.util.zip.ZipFile.(java.base at 21/Unknown Source) > at java.util.zip.ZipFile.(java.base at 21/Unknown Source) > at java.util.jar.JarFile.(java.base at 21/Unknown Source) > at java.util.jar.JarFile.(java.base at 21/Unknown Source) > at java.util.jar.JarFile.(java.base at 21/Unknown Source) > at sun.launcher.LauncherHelper.getMainClassFromJar(java.base at 21/Unknown Source) > at sun.launcher.LauncherHelper.loadMainClass(java.base at 21/Unknown Source) > at sun.launcher.LauncherHelper.checkAndLoadMain(java.base at 21/Unknown Source) > Aborted > > > With 1.2.4 everything works fine. > > > Farther debugging revealed that following fix in Java allowed to run it > with 1.2.5: > > Index: openjdk-21.0.9+6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > =================================================================== > --- openjdk-21.0.9+6.orig/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > +++ openjdk-21.0.9+6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > @@ -430,7 +430,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_ini > capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_BIRTHTIME; > #endif > #if defined(__linux__) > - my_statx_func = (statx_func*) dlsym(RTLD_DEFAULT, "statx"); > + my_statx_func = NULL; > if (my_statx_func != NULL) { > capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_BIRTHTIME; > } > > > May be this has something to do with the stat ./. stat64 stuff changed > in musl from 1.2.4 to 1.2.5 or so. > I already headed to the musl people but I am not shure if its placed > better over there or here. I also already showed up at client-libs-dev > but was told to be come over here. > > Kind Regards > Konstantin > From rriggs at openjdk.org Thu Sep 11 01:35:10 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 11 Sep 2025 01:35:10 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> Message-ID: <2UwoeXkl4uwciPrKPyU9yplzk6Id1QGQKt04i-_SjIM=.dbc82e76-c43a-400c-b6ae-4a7c8ea0e80c@github.com> On Wed, 10 Sep 2025 22:05:26 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Found additional place where new API can be used. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 356: > 354: // Unlike findNode(), this method makes only one lookup in the > 355: // underlying jimage, but can only reliably return resource nodes. > 356: if (moduleName.contains("/") || resourcePath.startsWith("/")) { Slightly more efficient, here and in `containsResource` below: Suggestion: if (moduleName.indexOf('/') >= 0 || resourcePath.indexOf('/') == 0) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2338275490 From rriggs at openjdk.org Thu Sep 11 01:35:12 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 11 Sep 2025 01:35:12 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> Message-ID: On Thu, 11 Sep 2025 00:34:00 GMT, David Beaumont wrote: >> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 379: >> >>> 377: // exist, so it skips checking the nodes cache and only checks for >>> 378: // an ImageLocation. >>> 379: if (moduleName.contains("/") || resourcePath.startsWith("/")) { >> >> The fast-path guard here and above might improve if they were done before synchronizing, e.g. dropping the modifier and putting a `synchonized (this)` block around the rest of the method. >> >> Putting the likely cheaper `resourcePath.startsWith` first might be a small win, too, depending on input/benchmark. > > When called from SystemModuleFinders this really should never happen (arguably it's IAE) so it won't make a difference per-call if it's changed, and it won't really help reduce the time of the locked section. > Both checks will basically always be done, so ordering isn't an issue (but a fair point to raise). > > Module names are typically short, so while a string scan is not ideal, it's not awful (and we do string concatentaion later anyway). Ideally there would be a ModuleName type to use as the parameter. While you are at it, both findNode and BuildModulesNode should have comments indicating that the node can be found in one of two places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2338286808 From liach at openjdk.org Thu Sep 11 03:15:10 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 11 Sep 2025 03:15:10 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> Message-ID: On Thu, 11 Sep 2025 01:31:07 GMT, Roger Riggs wrote: >> When called from SystemModuleFinders this really should never happen (arguably it's IAE) so it won't make a difference per-call if it's changed, and it won't really help reduce the time of the locked section. >> Both checks will basically always be done, so ordering isn't an issue (but a fair point to raise). >> >> Module names are typically short, so while a string scan is not ideal, it's not awful (and we do string concatentaion later anyway). Ideally there would be a ModuleName type to use as the parameter. > > While you are at it, both findNode and BuildModulesNode should have comments indicating that the node can be found in one of two places. If something shouldn't happen, I would prefer an explicit exception or at least an assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2338400975 From iklam at openjdk.org Thu Sep 11 04:43:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Sep 2025 04:43:48 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation Message-ID: This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to - All of `K`'s super classes - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. ------------- Commit messages: - Added javadoc; added test case; code clean up - Merge branch 'master' into aot-initialize-math-utils - cleanup - Merge branch 'master' into aot-initialize-math-utils - Merge branch '8366477-refactor-aot-related-flag-bits-in-klass-hpp' into aot-initialize-math-utils - Merge branch 'master' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp - @liach and @ashu-mehra comment: Renamed Klass::_is_generated_shared_class -> _is_aot_generated_class - Merge branch 'master' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp.saved - Move annotation validation to AOTClassInitializer::check_aot_annotations() - Force AOT initialization of MathUtils in assembly phase - ... and 8 more: https://git.openjdk.org/jdk/compare/134c3ef4...5b71ce80 Changes: https://git.openjdk.org/jdk/pull/27024/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367387 Stats: 316 lines in 10 files changed: 263 ins; 49 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From jpai at openjdk.org Thu Sep 11 05:29:28 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Sep 2025 05:29:28 GMT Subject: RFR: 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 21:03:32 GMT, Roger Riggs wrote: > JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c:306 > Minor cleanup of a missing check for exception pending. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27202#pullrequestreview-3208882848 From jpai at openjdk.org Thu Sep 11 06:17:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Sep 2025 06:17:52 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3209058486 From djelinski at openjdk.org Thu Sep 11 06:30:50 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 11 Sep 2025 06:30:50 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3209123887 From alanb at openjdk.org Thu Sep 11 06:35:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Sep 2025 06:35:42 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. > > As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run. > @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this. ACK, I'll get to it shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3278424046 From tschatzl at openjdk.org Thu Sep 11 07:26:25 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 07:26:25 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:28:39 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review That test failure in windows-x64 is a shenandoah timeout that looks unrelated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3278828076 From rgiulietti at openjdk.org Thu Sep 11 09:03:03 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 11 Sep 2025 09:03:03 GMT Subject: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout Message-ID: This PR * Moves sqrt() and nthRoot() tests to a new subset. * Removes a leftover `@run` tag without a timeout. * Increases the explicit timeout from 400 to 480. * Sorts the jtreg tags according to standard conventions. ------------- Commit messages: - 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout Changes: https://git.openjdk.org/jdk/pull/27211/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27211&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367365 Stats: 23 lines in 1 file changed: 10 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27211.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27211/head:pull/27211 PR: https://git.openjdk.org/jdk/pull/27211 From alanb at openjdk.org Thu Sep 11 09:29:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Sep 2025 09:29:46 GMT Subject: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:55:02 GMT, Raffaello Giulietti wrote: > This PR > * Moves sqrt() and nthRoot() tests to a new subset. > * Removes a leftover `@run` tag without a timeout. > * Increases the explicit timeout from 400 to 480. > * Sorts the jtreg tags according to standard conventions. test/jdk/java/math/BigInteger/BigIntegerTest.java line 32: > 30: * @library /test/lib > 31: * @build jdk.test.lib.RandomFactory > 32: * @run main/timeout=480 BigIntegerTest Should the timeoutFactor change have adjusted this from 400 to 1600? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27211#discussion_r2339733700 From ihse at openjdk.org Thu Sep 11 09:30:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 11 Sep 2025 09:30:53 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 23:29:03 GMT, Jiangli Zhou wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on review > > src/java.base/share/native/launcher/main.c line 41: > >> 39: >> 40: // This is reported when requesting a full version >> 41: static char* launcher = LAUNCHER_NAME; > > Is it guaranteed that `LAUNCHER_NAME` is always defined at build time? Is it safer to keep the `ifdef LAUNCHER_NAME` check and initialize `launcer` to `NULL` if `LAUNCHER_NAME` is not defined? From removed defines.h: > > > #ifdef LAUNCHER_NAME > static const char* const_launcher = LAUNCHER_NAME; > #else /* LAUNCHER_NAME */ > static char* const_launcher = NULL; > #endif /* LAUNCHER_NAME */ Yes, it is guaranteed. It is always passed by the make files, and have been for a very long time. That ifdef has not been needed since the "new" build system, so maybe it was needed in JDK 7 or prior... > src/java.base/windows/native/launcher/relauncher.c line 1: > >> 1: /* > > How did you test the relauncher for Windows? Can you remind me if static JDK is support for Windows? Yes, static JDK is supported on all supported platforms. I just ran simple adhoc tests on the command line, checking that a select subset of the launchers worked, like jar, jlink and javac. My assumption was that if they just started fine, then there were no reason to test the full functionality, since this patch is just about getting them launched. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2339724736 PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2339737476 From rgiulietti at openjdk.org Thu Sep 11 09:37:53 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 11 Sep 2025 09:37:53 GMT Subject: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout In-Reply-To: References: Message-ID: <5oRywF8GmErnfJMGaGa_3kNKeUAtG9JrcG2Ald4nC94=.295e86eb-b08d-4b24-ba07-850cb909def3@github.com> On Thu, 11 Sep 2025 09:27:06 GMT, Alan Bateman wrote: >> This PR >> * Moves sqrt() and nthRoot() tests to a new subset. >> * Removes a leftover `@run` tag without a timeout. >> * Increases the explicit timeout from 400 to 480. >> * Sorts the jtreg tags according to standard conventions. > > test/jdk/java/math/BigInteger/BigIntegerTest.java line 32: > >> 30: * @library /test/lib >> 31: * @build jdk.test.lib.RandomFactory >> 32: * @run main/timeout=480 BigIntegerTest > > Should the timeoutFactor change have adjusted this from 400 to 1600? There were two `@run` lines, one without a timeout (which is now removed), and a later one with a timeout of 400. IIUC, this means that the test was executed 2 times, one with a default timeout, and another with the explicit timeout of 400. The JBS issue shows a timeout after 120 seconds, so I guess this was due to the first `@run` line without an explicit timeout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27211#discussion_r2339770690 From ihse at openjdk.org Thu Sep 11 09:40:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 11 Sep 2025 09:40:58 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v7] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' into static-relaunchers - Update based on review - Merge branch 'master' into static-relaunchers - Use ReadFile instead - Merge branch 'master' into static-relaunchers - Remove problemlisting - Merge branch 'master' into static-relaunchers - Improve windows runtime lib copying - Fix linux launcher to allow relaunching - Copy Windows runtime libs - ... and 9 more: https://git.openjdk.org/jdk/compare/3d679087...62980659 ------------- Changes: https://git.openjdk.org/jdk/pull/24380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=06 Stats: 814 lines in 14 files changed: 624 ins; 144 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From ihse at openjdk.org Thu Sep 11 09:41:01 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 11 Sep 2025 09:41:01 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v6] In-Reply-To: References: Message-ID: <42eBed988TwesF1JmAa_QD48HKU0bRGQcz7nPR32Xmk=.c5c4566a-6a9e-4098-be1e-e8f3f1de8b05@github.com> On Wed, 10 Sep 2025 23:36:08 GMT, Jiangli Zhou wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on review > > src/java.base/share/native/launcher/main.c line 44: > >> 42: >> 43: // This is used as the name of the executable in the help message >> 44: static char* progname = PROGNAME; > > Same question for `PROGNAME` as the one for `LAUNCHER_NAME` above. And same reply here. It is always passed from the makefile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2339780842 From ihse at openjdk.org Thu Sep 11 09:41:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 11 Sep 2025 09:41:04 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v6] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 09:27:51 GMT, Magnus Ihse Bursie wrote: >> src/java.base/windows/native/launcher/relauncher.c line 1: >> >>> 1: /* >> >> How did you test the relauncher for Windows? Can you remind me if static JDK is support for Windows? > > Yes, static JDK is supported on all supported platforms. > > I just ran simple adhoc tests on the command line, checking that a select subset of the launchers worked, like jar, jlink and javac. My assumption was that if they just started fine, then there were no reason to test the full functionality, since this patch is just about getting them launched. Also, I've emptied the problem lists for static builds. (I kept the actual ProblemList files for now, if it turns out we find other tests that are problematic.) If there was a problem with launching e.g. `jar`, then those tests should have failed. Now it has passed some time since I ran the tests, so I'll start a comprehensive test suite again on this PR, just to make sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2339753600 From duke at openjdk.org Thu Sep 11 10:01:28 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 10:01:28 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: <2UwoeXkl4uwciPrKPyU9yplzk6Id1QGQKt04i-_SjIM=.dbc82e76-c43a-400c-b6ae-4a7c8ea0e80c@github.com> References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> <2UwoeXkl4uwciPrKPyU9yplzk6Id1QGQKt04i-_SjIM=.dbc82e76-c43a-400c-b6ae-4a7c8ea0e80c@github.com> Message-ID: On Thu, 11 Sep 2025 01:19:17 GMT, Roger Riggs wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Found additional place where new API can be used. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 356: > >> 354: // Unlike findNode(), this method makes only one lookup in the >> 355: // underlying jimage, but can only reliably return resource nodes. >> 356: if (moduleName.contains("/") || resourcePath.startsWith("/")) { > > Slightly more efficient, here and in `containsResource` below: > Suggestion: > > if (moduleName.indexOf('/') >= 0 || resourcePath.indexOf('/') == 0) { I had thought of these micro optimizations, but I thought we preferred clarity unless performance was proven to be an issue. I see contains("") in other code - should we be changing that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2339893442 From duke at openjdk.org Thu Sep 11 10:01:30 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 10:01:30 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> Message-ID: On Thu, 11 Sep 2025 03:12:33 GMT, Chen Liang wrote: >> While you are at it, both findNode and BuildModulesNode should have comments indicating that the node can be found in one of two places. > > If something shouldn't happen, I would prefer an explicit exception or at least an assert. Not 100% sure it's impossible to tickle this with current callers (e.g. "jrt:/module//path" leaving the trailing path starting with a '/') so I'd rather not risk triggering IAE in existing code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2339884131 From ihse at openjdk.org Thu Sep 11 10:07:05 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 11 Sep 2025 10:07:05 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v8] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Use strlen to get literal string lenght ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24380/files - new: https://git.openjdk.org/jdk/pull/24380/files/62980659..9881813d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=06-07 Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From amitkumar at openjdk.org Thu Sep 11 10:24:12 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 11 Sep 2025 10:24:12 GMT Subject: RFR: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() [v2] In-Reply-To: References: Message-ID: <6rxZ4FJsaAVrhzfCwszU9_Qsyb4WoZvwywKALJdos1w=.99f052eb-a5c2-43e2-ad1d-ee805926f60f@github.com> On Tue, 2 Sep 2025 09:43:23 GMT, Amit Kumar wrote: >> Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 >> >> These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): >> >> java/foreign/TestFill.java >> java/foreign/TestSegments.java >> java/foreign/TestSegmentBulkOperationsContentHash.java >> java/foreign/TestStringEncoding.java >> java/foreign/TestVarArgs.java >> >> >> >> ```java >> // Always allocate at least some memory so that zero-length segments have distinct >> // non-zero addresses. >> alignedSize = Math.max(1, alignedSize); >> >> >> Here minimum-allocated size will be 1, which is incorrect because >> >> >> private static void initNativeMemory(long address, long byteSize) { >> for (long i = 0; i < byteSize; i += Long.BYTES) { >> UNSAFE.putLongUnaligned(null, address + i, 0); >> } >> } >> >> `initNativeMemory()` is going to write Long. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > update Not sure what happened to [JDK-8366495](https://bugs.openjdk.org/browse/JDK-8366495), for sure I remember I created this issue, now I am not able to access it. @jaikiran any suggestions ? are you able to access it ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27027#issuecomment-3279756579 From aph at openjdk.org Thu Sep 11 10:28:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 11 Sep 2025 10:28:16 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 11:38:38 GMT, Thomas Schatzl wrote: > I can argue I was following precedent :) You were, but it's a precedent that needs to die. > I see your point though. What do you suggest to do here? Use `count` throughout instead? Yes, although it might need a couple more comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2340016401 From duke at openjdk.org Thu Sep 11 10:43:55 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 10:43:55 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v3] In-Reply-To: References: Message-ID: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/2cdb1b22..93151867 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=01-02 Stats: 33 lines in 1 file changed: 15 ins; 6 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From dfuchs at openjdk.org Thu Sep 11 10:55:09 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 11 Sep 2025 10:55:09 GMT Subject: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:55:02 GMT, Raffaello Giulietti wrote: > This PR > * Moves sqrt() and nthRoot() tests to a new subset. > * Removes a leftover `@run` tag without a timeout. > * Increases the explicit timeout from 400 to 480. > * Sorts the jtreg tags according to standard conventions. LGTM - but I'm not a regular reviewer in this area. I guess the main question is whether Reviewers will be on board with the idea of having this new subset (as it means chances to run it are now 25% instead of 33%...) Personally I think it's a good idea if it makes the time each subset needs to complete more homogeneous. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27211#pullrequestreview-3210628945 From dfuchs at openjdk.org Thu Sep 11 10:55:11 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 11 Sep 2025 10:55:11 GMT Subject: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout In-Reply-To: <5oRywF8GmErnfJMGaGa_3kNKeUAtG9JrcG2Ald4nC94=.295e86eb-b08d-4b24-ba07-850cb909def3@github.com> References: <5oRywF8GmErnfJMGaGa_3kNKeUAtG9JrcG2Ald4nC94=.295e86eb-b08d-4b24-ba07-850cb909def3@github.com> Message-ID: <8DaYt0xQElx-Hntl1gIDUQj3vk-lXVCsY63ijkczHtE=.aa6ca837-706a-48f3-bc5c-57be78281226@github.com> On Thu, 11 Sep 2025 09:34:59 GMT, Raffaello Giulietti wrote: >> test/jdk/java/math/BigInteger/BigIntegerTest.java line 32: >> >>> 30: * @library /test/lib >>> 31: * @build jdk.test.lib.RandomFactory >>> 32: * @run main/timeout=480 BigIntegerTest >> >> Should the timeoutFactor change have adjusted this from 400 to 1600? > > There were two `@run` lines, one without a timeout (which is now removed), and a later one with a timeout of 400. > IIUC, this means that the test was executed 2 times, one with a default timeout, and another with the explicit timeout of 400. > > The JBS issue shows a timeout after 120 seconds, so I guess this was due to the first `@run` line without an explicit timeout. Yes - the observed timeout was 120s - so it must have been the first `@run`. That first `@run` was added by [JDK-8078672](https://bugs.openjdk.org/browse/JDK-8078672) - I'm not sure why - that might have been a left over from debugging... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27211#discussion_r2340093654 From lancea at openjdk.org Thu Sep 11 11:11:26 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 11 Sep 2025 11:11:26 GMT Subject: RFR: 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 21:03:32 GMT, Roger Riggs wrote: > JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c:306 > Minor cleanup of a missing check for exception pending. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27202#pullrequestreview-3210782069 From duke at openjdk.org Thu Sep 11 11:14:39 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 11:14:39 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v4] In-Reply-To: References: Message-ID: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Using alternate findLocation() API to avoid string creation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/93151867..9ec2db29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From redestad at openjdk.org Thu Sep 11 11:59:23 2025 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 11 Sep 2025 11:59:23 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> <2UwoeXkl4uwciPrKPyU9yplzk6Id1QGQKt04i-_SjIM=.dbc82e76-c43a-400c-b6ae-4a7c8ea0e80c@github.com> Message-ID: On Thu, 11 Sep 2025 09:58:19 GMT, David Beaumont wrote: >> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 356: >> >>> 354: // Unlike findNode(), this method makes only one lookup in the >>> 355: // underlying jimage, but can only reliably return resource nodes. >>> 356: if (moduleName.contains("/") || resourcePath.startsWith("/")) { >> >> Slightly more efficient, here and in `containsResource` below: >> Suggestion: >> >> if (moduleName.indexOf('/') >= 0 || resourcePath.indexOf('/') == 0) { > > I had thought of these micro optimizations, but I thought we preferred clarity unless performance was proven to be an issue. I see contains("<single-char>") in other code - should we be changing that? I think replacing `startsWith(String)` with `indexOf(char)` is dubious, since the latter is O(n) and the former O(1) If you _really_ need to squeeze out everything on startup then `(x.length() > 0 && x.charAt(0) == '/')` is slightly faster in the interpreter (the difference more or less disappears after JIT compilation). I'd keep using `startsWith("/")`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2340454223 From duke at openjdk.org Thu Sep 11 11:59:26 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 11:59:26 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 10:43:55 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Feedback. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 382: > 380: > 381: /** Returns whether a resource exists in the given module. */ > 382: boolean containsResource(String moduleName, String resourcePath) { I *think* I can drop synchronization here since I'm not using the nodes cache in this method. However I'm going to triple check that BasicImageReader is thread safe before going with this (it's not documented either way). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2340109756 From redestad at openjdk.org Thu Sep 11 12:06:47 2025 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 11 Sep 2025 12:06:47 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> <2UwoeXkl4uwciPrKPyU9yplzk6Id1QGQKt04i-_SjIM=.dbc82e76-c43a-400c-b6ae-4a7c8ea0e80c@github.com> Message-ID: <-y8JgUKTjRhOBssNIh1JZkZQiouLw19Uv1vBIsNfjR8=.0aa92b35-a327-467e-90e5-5e729767732d@github.com> On Thu, 11 Sep 2025 11:56:30 GMT, Claes Redestad wrote: >> I had thought of these micro optimizations, but I thought we preferred clarity unless performance was proven to be an issue. I see contains("<single-char>") in other code - should we be changing that? > > I think replacing `startsWith(String)` with `indexOf(char)` is dubious, since the latter is O(n) and the former O(1) > > If you _really_ need to squeeze out everything on startup then `(x.length() > 0 && x.charAt(0) == '/')` is slightly faster in the interpreter (the difference more or less disappears after JIT compilation). I'd keep using `startsWith("/")`. (Yes, `x.lastIndexOf('/', 0) == 0` is even faster for the interpreter, but let's keep it civil in these trying times.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2340467282 From duke at openjdk.org Thu Sep 11 12:06:49 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 12:06:49 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> Message-ID: On Thu, 11 Sep 2025 09:56:30 GMT, David Beaumont wrote: >> If something shouldn't happen, I would prefer an explicit exception or at least an assert. > > Not 100% sure it's impossible to tickle this with current callers (e.g. "jrt:/module//path" leaving the trailing path starting with a '/') so I'd rather not risk triggering IAE in existing code. Thinking about it, it might be sufficient to test that the module name doesn't contain '/'. I'm not sure that rejecting a leading '/' in the path matters for correctness (the implied resource name would be "/<mod>//<path>" and these never exist anyway). What I'm trying to protect against is having the concatentation of: "/" + <mod-name> + "/" + <path> be unexpectedly a different resource (e.g. module name is "java.base/java", path is "lang/Object.class"). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2340481195 From ihse at openjdk.org Thu Sep 11 12:13:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 11 Sep 2025 12:13:04 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove debug code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24380/files - new: https://git.openjdk.org/jdk/pull/24380/files/9881813d..e9925dab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From ihse at openjdk.org Thu Sep 11 12:13:06 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 11 Sep 2025 12:13:06 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 00:39:43 GMT, Jiangli Zhou wrote: >> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this. > >> @magicus I'll take a look today. > > Hi @magicus I looked at your changes and focused on the launcher changes. I only looked quickly of the build changes, I think @erikj79's review is sufficient. For launcher changes, my main question is Windows platform support (for static JDK) and testing. The rest of the comments are minor. I just realized that the testing I kicked off (tier1-5 on our internal CI) does not include running tests using the static-jdk. @jianglizhou Do you have any recommendation to the easiest way to use the static-jdk for testing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3280273927 From vklang at openjdk.org Thu Sep 11 12:35:27 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 11 Sep 2025 12:35:27 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v8] In-Reply-To: References: Message-ID: On Sun, 7 Sep 2025 18:28:54 GMT, Doug Lea
wrote: >> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > revive topLevelExec, adjust occrdingly; small teaks and copy-edits src/java.base/share/classes/java/util/concurrent/Exchanger.java line 276: > 274: static final class Node { > 275: long seed; // Random seed > 276: int index; // Arena index Just adding it here as a reminder (to myself if nothing else) that the changes to Exchanger.java should be in a separate PR for easier handling. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 575: > 573: * or non-emptiness; all of which usually cause more activations > 574: * than necessary (see below). (Method signalWork is also used as > 575: * failsafe in case of Thread failures in deregisterWorker.) I think it is worth elaborating what this failsafe enables (i.e. how does it failsafe these failures) src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 598: > 596: * needs unparking upon signal. > 597: * > 598: * When tasks are constructed as (recursive) dags, top-level Suggestion: * When tasks are constructed as (recursive) DAGs, top-level src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 605: > 603: * empty or contended, while also minimizing interference by > 604: * postponing bookeeping to ends of runs. This may reduce > 605: * fairness, which is partially counteracted by the following. This sentence ends in a weird manner for me. Is the intention that the dot should be a colon? Or is there missing text? src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 612: > 610: * stalls when tasks cannot be taken because other workers have > 611: * not finished poll operations, which is detected by reading > 612: * ahead in queue arrays. In both caes, workers restart scans in a Suggestion: * ahead in queue arrays. In both cases, workers restart scans in a ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2340616981 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2340606205 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2340607680 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2340612511 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2340613633 From jpai at openjdk.org Thu Sep 11 12:58:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Sep 2025 12:58:53 GMT Subject: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout In-Reply-To: <8DaYt0xQElx-Hntl1gIDUQj3vk-lXVCsY63ijkczHtE=.aa6ca837-706a-48f3-bc5c-57be78281226@github.com> References: <5oRywF8GmErnfJMGaGa_3kNKeUAtG9JrcG2Ald4nC94=.295e86eb-b08d-4b24-ba07-850cb909def3@github.com> <8DaYt0xQElx-Hntl1gIDUQj3vk-lXVCsY63ijkczHtE=.aa6ca837-706a-48f3-bc5c-57be78281226@github.com> Message-ID: <1p7XONAh30d1UDTzPNyGCwUd6sgsL42eoYrlizxZ7eI=.cb5c16ee-e1bf-4867-ad81-b92e3f19d829@github.com> On Thu, 11 Sep 2025 10:42:31 GMT, Daniel Fuchs wrote: >> There were two `@run` lines, one without a timeout (which is now removed), and a later one with a timeout of 400. >> IIUC, this means that the test was executed 2 times, one with a default timeout, and another with the explicit timeout of 400. >> >> The JBS issue shows a timeout after 120 seconds, so I guess this was due to the first `@run` line without an explicit timeout. > > Yes - the observed timeout was 120s - so it must have been the first `@run`. That first `@run` was added by [JDK-8078672](https://bugs.openjdk.org/browse/JDK-8078672) - I'm not sure why - that might have been a left over from debugging... Hello Raffaello, > The JBS issue shows a timeout after 120 seconds, so I guess this was due to the first @run line without an explicit timeout. More as a general note than a review of this change - when a test action times out, jtreg prints the timeout information in that test action's "section" (each test action has a "section" of its own in the jtr report file). That section will additionally also include the literal definition of the test action. In the case of this timeout failure that happened in our CI, that section looks like: #section:main ----------messages:(11/327)---------- command: main BigIntegerTest reason: User specified action: run main BigIntegerTest started: Wed Sep 10 17:58:16 UTC 2025 ... Timeout signalled after 120 seconds Timeout information: --- Timeout information end. finished: Wed Sep 10 18:01:11 UTC 2025 elapsed time (seconds): 174.678 Notice the "reason" in that section, that's where the test action's literal definition is printed. In this case (as you note), it was the `@run main BigIntegerTest` which timed out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27211#discussion_r2340729303 From jpai at openjdk.org Thu Sep 11 13:04:16 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Sep 2025 13:04:16 GMT Subject: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:55:02 GMT, Raffaello Giulietti wrote: > This PR > * Moves sqrt() and nthRoot() tests to a new subset. > * Removes a leftover `@run` tag without a timeout. > * Increases the explicit timeout from 400 to 480. > * Sorts the jtreg tags according to standard conventions. The removal of the duplicate `@run` looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27211#pullrequestreview-3211432562 From rgiulietti at openjdk.org Thu Sep 11 13:12:21 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 11 Sep 2025 13:12:21 GMT Subject: RFR: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout In-Reply-To: <1p7XONAh30d1UDTzPNyGCwUd6sgsL42eoYrlizxZ7eI=.cb5c16ee-e1bf-4867-ad81-b92e3f19d829@github.com> References: <5oRywF8GmErnfJMGaGa_3kNKeUAtG9JrcG2Ald4nC94=.295e86eb-b08d-4b24-ba07-850cb909def3@github.com> <8DaYt0xQElx-Hntl1gIDUQj3vk-lXVCsY63ijkczHtE=.aa6ca837-706a-48f3-bc5c-57be78281226@github.com> <1p7XONAh30d1UDTzPNyGCwUd6sgsL42eoYrlizxZ7eI=.cb5c16ee-e1bf-4867-ad81-b92e3f19d829@github.com> Message-ID: <6Ph4ZgrNAWWVlAfimk7_GzAIyI_W47DmYcR-PeOG26M=.8196f482-6926-4d80-9c38-567d12ebd5d2@github.com> On Thu, 11 Sep 2025 12:56:33 GMT, Jaikiran Pai wrote: >> Yes - the observed timeout was 120s - so it must have been the first `@run`. That first `@run` was added by [JDK-8078672](https://bugs.openjdk.org/browse/JDK-8078672) - I'm not sure why - that might have been a left over from debugging... > > Hello Raffaello, > >> The JBS issue shows a timeout after 120 seconds, so I guess this was due to the first @run line without an explicit timeout. > > More as a general note than a review of this change - when a test action times out, jtreg prints the timeout information in that test action's "section" (each test action has a "section" of its own in the jtr report file). That section will additionally also include the literal definition of the test action. In the case of this timeout failure that happened in our CI, that section looks like: > > > #section:main > ----------messages:(11/327)---------- > command: main BigIntegerTest > reason: User specified action: run main BigIntegerTest > started: Wed Sep 10 17:58:16 UTC 2025 > ... > Timeout signalled after 120 seconds > Timeout information: > --- Timeout information end. > finished: Wed Sep 10 18:01:11 UTC 2025 > elapsed time (seconds): 174.678 > > Notice the "reason" in that section, that's where the test action's literal definition is printed. In this case (as you note), it was the `@run main BigIntegerTest` which timed out. Thank Jai for the explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27211#discussion_r2340781288 From vklang at openjdk.org Thu Sep 11 13:21:00 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 11 Sep 2025 13:21:00 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v8] In-Reply-To: References: Message-ID: <-ZEFYOv3-bUzr6LKuRv4WPerx9uflUIdJ2-PKiB6T-k=.d49a4e9e-39e9-4258-a04e-d0f49705e801@github.com> On Sun, 7 Sep 2025 18:28:54 GMT, Doug Lea
wrote: >> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > revive topLevelExec, adjust occrdingly; small teaks and copy-edits src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1224: > 1222: if ((this.owner = owner) == null) { > 1223: phase = id | IDLE; > 1224: array = new ForkJoinTask[INITIAL_QUEUE_CAPACITY]; Might be better to assign the array *before* assigning the phase as the latter is a volatile write? src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1951: > 1949: final void runWorker(WorkQueue w) { > 1950: if (w != null) { > 1951: int phase = w.phase; Given that this is a volatile read, and presuming that the timing of this read is important, perhaps add a comment on this line? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2340815858 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2340822551 From rriggs at openjdk.org Thu Sep 11 13:25:20 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 11 Sep 2025 13:25:20 GMT Subject: Integrated: 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 21:03:32 GMT, Roger Riggs wrote: > JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c:306 > Minor cleanup of a missing check for exception pending. This pull request has now been integrated. Changeset: 56f2f7a3 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/56f2f7a3af0574357d5d3f99dcd908721ac710e9 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8367138: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_macosx.c Reviewed-by: bpb, naoto, jpai, lancea ------------- PR: https://git.openjdk.org/jdk/pull/27202 From rriggs at openjdk.org Thu Sep 11 14:02:12 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 11 Sep 2025 14:02:12 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v14] In-Reply-To: References: Message-ID: <_pM8QyWX3pq5W5B6vAcHiad9a6Ypz4_J_eGWdyptZD4=.afb328da-baf8-4d9a-9413-8fa14e69a140@github.com> On Wed, 10 Sep 2025 19:46:12 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > update method name Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25303#pullrequestreview-3211793194 From rriggs at openjdk.org Thu Sep 11 14:02:16 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 11 Sep 2025 14:02:16 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v13] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 19:57:56 GMT, Kieran Farrell wrote: >> test/jdk/java/util/UUID/UUIDTest.java line 52: >> >>> 50: unixEpochTimeMillisTest(); >>> 51: unixEpochTimeMillisTest_Multi(); >>> 52: unixEpochTimeMillis_userInputTest(); >> >> Also rename the tests to use the `epochMillis` naming. > > Thanks Roger, I have updated the name accordingly. WRT updating the implementation to use nextLong(), since we are no longer using the higher percision bits in the first half of the UUID, we are using random bits in their place, so we would need to call `nextLong` twice and overwrite with the timestamp etc. if I understand correctly. From what ive seen in the microbenchmarks, this results in a large perfomance dec. ok, looks good, allow some time for the other interested commenters to approve. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2341017995 From duke at openjdk.org Thu Sep 11 14:42:07 2025 From: duke at openjdk.org (Johannes Graham) Date: Thu, 11 Sep 2025 14:42:07 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v2] In-Reply-To: <_ZwF0CJ0mY-x-ie19mhkUiTnLlBlDBG6-zCzKaLfbyU=.e8f9d819-d67b-4b31-b19c-3369c69da5ef@github.com> References: <_ZwF0CJ0mY-x-ie19mhkUiTnLlBlDBG6-zCzKaLfbyU=.e8f9d819-d67b-4b31-b19c-3369c69da5ef@github.com> Message-ID: On Wed, 10 Sep 2025 23:47:47 GMT, Johannes Graham wrote: >> When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. >> >> This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. > > Johannes Graham has updated the pull request incrementally with two additional commits since the last revision: > > - use Level.Invocation > - review fixes Updated Benchmark numbers using `@Setup(Level.Invocation)` Baseline Benchmark Mode Cnt Score Error Units DefFormatterBench.testDefNumberFormatter thrpt 15 14493.498 ? 240.094 ops/ms DefFormatterBench.testLargeBigDecDefNumberFormatter thrpt 15 3680.037 ? 90.755 ops/ms DefFormatterBench.testSmallBigDecDefNumberFormatter thrpt 15 18270.715 ? 666.360 ops/ms This PR without BigInteger fast-path Benchmark Mode Cnt Score Error Units DefFormatterBench.testDefNumberFormatter thrpt 15 18463.554 ? 540.881 ops/ms +27% DefFormatterBench.testLargeBigDecDefNumberFormatter thrpt 15 4416.749 ? 81.965 ops/ms +20% DefFormatterBench.testSmallBigDecDefNumberFormatter thrpt 15 14829.697 ? 235.140 ops/ms -18% This PR with fast-path Benchmark Mode Cnt Score Error Units DefFormatterBench.testDefNumberFormatter thrpt 15 18926.301 ? 346.970 ops/ms +30% DefFormatterBench.testLargeBigDecDefNumberFormatter thrpt 15 4511.169 ? 65.314 ops/ms +23% DefFormatterBench.testSmallBigDecDefNumberFormatter thrpt 15 25409.301 ? 630.107 ops/ms +39% ------------- PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3281137706 From rgiulietti at openjdk.org Thu Sep 11 15:03:35 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 11 Sep 2025 15:03:35 GMT Subject: Integrated: 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout In-Reply-To: References: Message-ID: <-NSQtX8wgSUpSnY_Jmr-xHSqlC3AbWBPWUqmdjYIQNk=.71cb34e2-a663-4aca-8b16-2fc5442f16f9@github.com> On Thu, 11 Sep 2025 08:55:02 GMT, Raffaello Giulietti wrote: > This PR > * Moves sqrt() and nthRoot() tests to a new subset. > * Removes a leftover `@run` tag without a timeout. > * Increases the explicit timeout from 400 to 480. > * Sorts the jtreg tags according to standard conventions. This pull request has now been integrated. Changeset: 8b92af7d Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/8b92af7d4aeece8b40c6c4f9de333964833da607 Stats: 23 lines in 1 file changed: 10 ins; 9 del; 4 mod 8367365: java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout Reviewed-by: dfuchs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27211 From kfarrell at openjdk.org Thu Sep 11 15:06:59 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 11 Sep 2025 15:06:59 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v13] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 13:59:07 GMT, Roger Riggs wrote: >> Thanks Roger, I have updated the name accordingly. WRT updating the implementation to use nextLong(), since we are no longer using the higher percision bits in the first half of the UUID, we are using random bits in their place, so we would need to call `nextLong` twice and overwrite with the timestamp etc. if I understand correctly. From what ive seen in the microbenchmarks, this results in a large perfomance dec. > > ok, looks good, allow some time for the other interested commenters to approve. will do, thanks Roger ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2341331534 From rriggs at openjdk.org Thu Sep 11 15:21:35 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 11 Sep 2025 15:21:35 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v16] In-Reply-To: <-BkePe544FgYOqAXdW3apKhLEro5_7rtBkvVs9CjoNA=.6e8eb1b8-fd4a-4e79-a90b-2881a3ab774a@github.com> References: <-BkePe544FgYOqAXdW3apKhLEro5_7rtBkvVs9CjoNA=.6e8eb1b8-fd4a-4e79-a90b-2881a3ab774a@github.com> Message-ID: On Tue, 9 Sep 2025 01:05:37 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java > > Improve error log Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26802#pullrequestreview-3212299025 From duke at openjdk.org Thu Sep 11 15:35:18 2025 From: duke at openjdk.org (duke) Date: Thu, 11 Sep 2025 15:35:18 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v16] In-Reply-To: <-BkePe544FgYOqAXdW3apKhLEro5_7rtBkvVs9CjoNA=.6e8eb1b8-fd4a-4e79-a90b-2881a3ab774a@github.com> References: <-BkePe544FgYOqAXdW3apKhLEro5_7rtBkvVs9CjoNA=.6e8eb1b8-fd4a-4e79-a90b-2881a3ab774a@github.com> Message-ID: On Tue, 9 Sep 2025 01:05:37 GMT, Guanqiang Han wrote: >> Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. > > Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java > > Improve error log @hgqxjj Your change (at version acc85bd79bb883e68584c4abfa06b4fd12e7b3e9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3281460105 From ghan at openjdk.org Thu Sep 11 15:39:44 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 11 Sep 2025 15:39:44 GMT Subject: RFR: 8328874: Class::forName0 should validate the class name length early [v12] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 18:40:26 GMT, Roger Riggs wrote: >> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Class.java >> >> change overflow check > >> /reviewers 2 reviewer >> >> I recommend putting this PR on hold - 65535 encoded size for modified utf8 is significant enough for a cross-JDK utility. As @rose00 suggested, I think I will explore adding a check in ClassFile API, and sharing the check with here. > > A common boolean function is useful and can be better optimized. > The function should be in a common utility area, but the ClassFile API is a higher level API specific to class files. > Most developers won't think to look there. The jdk.internal.util.ModifiedUtf isn't a bad place for both the boolean function and the utfLen function. Many thanks to @RogerRiggs and @liach for your thorough feedback and patience on this PR. I?ve integrated the changes ? could one of you kindly sponsor it? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26802#issuecomment-3281475739 From duke at openjdk.org Thu Sep 11 15:59:54 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 15:59:54 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v5] In-Reply-To: References: Message-ID: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary path check and added extra test for modules not being returned. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/9ec2db29..18f23327 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=03-04 Stats: 29 lines in 2 files changed: 19 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From alanb at openjdk.org Thu Sep 11 16:17:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Sep 2025 16:17:03 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v5] In-Reply-To: References: Message-ID: <83kECmxxJpPXZ5tjkA_zNJ8MzlKJrN5xceGZIaJxB48=.5d37be3c-d6b2-4489-a21b-db6fc98b4c85@github.com> On Thu, 11 Sep 2025 15:59:54 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary path check and added extra test for modules not being returned. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 331: > 329: if (name.startsWith(MODULES_ROOT + "/")) { > 330: // This may preform two lookups, one for a directory (in > 331: // /modules/...) and one for a non-prefixed resource. Would it be possible to provide a summary on what a "non-prefixed resource" is? I realize there is comment from the previous change on this but I can't immediately see what this is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2341640466 From duke at openjdk.org Thu Sep 11 17:20:01 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 17:20:01 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 10:45:43 GMT, David Beaumont wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 382: > >> 380: >> 381: /** Returns whether a resource exists in the given module. */ >> 382: boolean containsResource(String moduleName, String resourcePath) { > > I *think* I can drop synchronization here since I'm not using the nodes cache in this method. However I'm going to triple check that BasicImageReader is thread safe before going with this (it's not documented either way). I've convinced myself by looking at the code that BasicImageReader is thread safe as it stands, so I'm confident the locking isn't needed here (but in preview mode in Valhalla some locking will have to come back). Please speak up now if you have any reason to suspect I'm wrong... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2341844363 From duke at openjdk.org Thu Sep 11 17:19:57 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 17:19:57 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v5] In-Reply-To: <83kECmxxJpPXZ5tjkA_zNJ8MzlKJrN5xceGZIaJxB48=.5d37be3c-d6b2-4489-a21b-db6fc98b4c85@github.com> References: <83kECmxxJpPXZ5tjkA_zNJ8MzlKJrN5xceGZIaJxB48=.5d37be3c-d6b2-4489-a21b-db6fc98b4c85@github.com> Message-ID: On Thu, 11 Sep 2025 16:14:10 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unnecessary path check and added extra test for modules not being returned. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 331: > >> 329: if (name.startsWith(MODULES_ROOT + "/")) { >> 330: // This may preform two lookups, one for a directory (in >> 331: // /modules/...) and one for a non-prefixed resource. > > Would it be possible to provide a summary on what a "non-prefixed resource" is? I realize there is comment from the previous change on this but I can't immediately see what this is. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2341844515 From duke at openjdk.org Thu Sep 11 17:22:27 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 17:22:27 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v6] In-Reply-To: References: Message-ID: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Tweaked comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/18f23327..16f37d7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From darcy at openjdk.org Thu Sep 11 18:04:55 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 11 Sep 2025 18:04:55 GMT Subject: RFR: 8367382: Expand use of representation equivalence terminology Message-ID: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> Small doc enhancement to use the term "representation equivalence" in a few more locations. ------------- Commit messages: - JDK-8367382: Expand use of representation equivalence terminology Changes: https://git.openjdk.org/jdk/pull/27232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27232&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367382 Stats: 26 lines in 3 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27232/head:pull/27232 PR: https://git.openjdk.org/jdk/pull/27232 From jlu at openjdk.org Thu Sep 11 19:07:19 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 Sep 2025 19:07:19 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes Message-ID: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. ------------- Commit messages: - Reword w/o thread-safe - Reword - init Changes: https://git.openjdk.org/jdk/pull/27233/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27233&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367237 Stats: 16 lines in 2 files changed: 9 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27233/head:pull/27233 PR: https://git.openjdk.org/jdk/pull/27233 From duke at openjdk.org Thu Sep 11 19:12:06 2025 From: duke at openjdk.org (David Beaumont) Date: Thu, 11 Sep 2025 19:12:06 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v2] In-Reply-To: <-y8JgUKTjRhOBssNIh1JZkZQiouLw19Uv1vBIsNfjR8=.0aa92b35-a327-467e-90e5-5e729767732d@github.com> References: <7sYkdPGPHoHWEPNbZUHTAZ1yfE0tntzv1c0DKPFm1BY=.fa1282d3-59ca-446f-9666-13456e413498@github.com> <2UwoeXkl4uwciPrKPyU9yplzk6Id1QGQKt04i-_SjIM=.dbc82e76-c43a-400c-b6ae-4a7c8ea0e80c@github.com> <-y8JgUKTjRhOBssNIh1JZkZQiouLw19Uv1vBIsNfjR8=.0aa92b35-a327-467e-90e5-5e729767732d@github.com> Message-ID: On Thu, 11 Sep 2025 11:59:26 GMT, Claes Redestad wrote: >> I think replacing `startsWith(String)` with `indexOf(char)` is dubious, since the latter is O(n) and the former O(1) >> >> If you _really_ need to squeeze out everything on startup then `(x.length() > 0 && x.charAt(0) == '/')` is slightly faster in the interpreter (the difference more or less disappears after JIT compilation). I'd keep using `startsWith("/")`. > > (Yes, `x.lastIndexOf('/', 0) == 0` is even faster for the interpreter, but let's keep it civil in these trying times.) Oh good grief you're right, indexOf() == 0 is not a good idea. However, the good news is that I realized that could be removed (anything with / on the front leads to a // in the effective path and cannot resolve to anything. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2342095004 From eirbjo at openjdk.org Thu Sep 11 19:14:12 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 11 Sep 2025 19:14:12 GMT Subject: RFR: 8367382: Expand use of representation equivalence terminology In-Reply-To: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> References: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> Message-ID: On Thu, 11 Sep 2025 17:56:29 GMT, Joe Darcy wrote: > Small doc enhancement to use the term "representation equivalence" in a few more locations. src/java.base/share/classes/java/lang/Record.java line 132: > 130: * Note that these rules imply that {@linkplain > 131: * Double##repEquivalence representation equivalence} is used for > 132: * the equality comparison of both for primitive floating-point ?of both for?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27232#discussion_r2342099278 From naoto at openjdk.org Thu Sep 11 20:19:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 Sep 2025 20:19:52 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes In-Reply-To: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: On Thu, 11 Sep 2025 18:58:46 GMT, Justin Lu wrote: > Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. src/java.base/share/classes/java/text/Collator.java line 117: > 115: * > 116: * @implNote Concurrent usage of {@code Collator} instances returned by the factory > 117: * methods under the standard provider may lead to significant thread contention. "under the standard provider" may not be clear enough. How about "instances returned from the JDK's built-in implementation, `RuleBasedCollator`" or similar? src/java.base/share/classes/java/text/RuleBasedCollator.java line 241: > 239: * lead to significant thread contention. As such, users of this class should > 240: * consider creating a separate instance for each thread when used in > 241: * multithreaded environments. I'd add the reason behind, i.e., RuleBasedCollator uses `synchronized` to make it thread-safe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27233#discussion_r2342234118 PR Review Comment: https://git.openjdk.org/jdk/pull/27233#discussion_r2342236490 From jlu at openjdk.org Thu Sep 11 21:34:26 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 Sep 2025 21:34:26 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes [v2] In-Reply-To: References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: On Thu, 11 Sep 2025 20:14:56 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Doc updates reflecting Naoto's comments > > src/java.base/share/classes/java/text/Collator.java line 117: > >> 115: * >> 116: * @implNote Concurrent usage of {@code Collator} instances returned by the factory >> 117: * methods under the standard provider may lead to significant thread contention. > > "under the standard provider" may not be clear enough. How about "instances returned from the JDK's built-in implementation, `RuleBasedCollator`" or similar? OK, let me know what you think about the new wording. I want to emphasize that the factory methods (under the default provider) return such instances. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27233#discussion_r2342382050 From jlu at openjdk.org Thu Sep 11 21:34:24 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 Sep 2025 21:34:24 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes [v2] In-Reply-To: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: > Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Doc updates reflecting Naoto's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27233/files - new: https://git.openjdk.org/jdk/pull/27233/files/d15faad4..5fab9652 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27233&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27233&range=00-01 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27233/head:pull/27233 PR: https://git.openjdk.org/jdk/pull/27233 From iris at openjdk.org Thu Sep 11 22:29:12 2025 From: iris at openjdk.org (Iris Clark) Date: Thu, 11 Sep 2025 22:29:12 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes [v2] In-Reply-To: References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: <4WfvopCFGs8eBtBfMLEoqbPM-KsF7YHaqrIIlLlRIUo=.66ca0d19-9feb-4e93-8f67-f11669c17018@github.com> On Thu, 11 Sep 2025 21:34:24 GMT, Justin Lu wrote: >> Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Doc updates reflecting Naoto's comments This looks good. My only recommendation would be to change "JDK reference implementation" to "JDK Reference Implementation" (capitalize) following the prevalent convention in java.base. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27233#pullrequestreview-3213810594 From jlu at openjdk.org Thu Sep 11 22:36:28 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 Sep 2025 22:36:28 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes [v3] In-Reply-To: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: > Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Reflect Iris's comments: capitalize JDK RI ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27233/files - new: https://git.openjdk.org/jdk/pull/27233/files/5fab9652..d8c361f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27233&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27233&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27233/head:pull/27233 PR: https://git.openjdk.org/jdk/pull/27233 From naoto at openjdk.org Thu Sep 11 23:03:12 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 Sep 2025 23:03:12 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes [v3] In-Reply-To: References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: <7FGV1vE8Io0vmHqBlrKFIii1eT25Qh8jaeF7-boUz9Y=.a89593f5-58ec-45b6-b23a-de9262c709f0@github.com> On Thu, 11 Sep 2025 22:36:28 GMT, Justin Lu wrote: >> Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Reflect Iris's comments: capitalize JDK RI Both this PR and the CSR LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27233#pullrequestreview-3213915560 From iris at openjdk.org Thu Sep 11 23:09:14 2025 From: iris at openjdk.org (Iris Clark) Date: Thu, 11 Sep 2025 23:09:14 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes [v3] In-Reply-To: References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: On Thu, 11 Sep 2025 22:36:28 GMT, Justin Lu wrote: >> Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Reflect Iris's comments: capitalize JDK RI Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27233#pullrequestreview-3213953607 From stuart.marks at oracle.com Thu Sep 11 23:27:19 2025 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 11 Sep 2025 16:27:19 -0700 Subject: [External] : Re: Excessive copying of Collection.toArray() In-Reply-To: References: <4543dc86-0de7-47dd-8e3d-8872005d4d89@oracle.com> Message-ID: <56e272f8-7973-4830-b03b-0bf47b6677a0@oracle.com> (This deserves a reply, but I've been distracted by a bunch of other stuff recently. I should be able to continue this conversation in a few days. Sorry for the delay.) s'marks From darcy at openjdk.org Fri Sep 12 00:44:38 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 12 Sep 2025 00:44:38 GMT Subject: RFR: 8367382: Expand use of representation equivalence terminology [v2] In-Reply-To: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> References: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> Message-ID: > Small doc enhancement to use the term "representation equivalence" in a few more locations. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo found in code review. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27232/files - new: https://git.openjdk.org/jdk/pull/27232/files/0a4d8f26..5c7c92b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27232&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27232&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27232/head:pull/27232 PR: https://git.openjdk.org/jdk/pull/27232 From darcy at openjdk.org Fri Sep 12 00:44:39 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 12 Sep 2025 00:44:39 GMT Subject: RFR: 8367382: Expand use of representation equivalence terminology [v2] In-Reply-To: References: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> Message-ID: <09zEPX7OwBN1o3TTzdIgyRa-2iJJtilN5Mw_F-h52EY=.65f23d58-8294-44ca-977d-3ae5b4f388ca@github.com> On Thu, 11 Sep 2025 19:10:57 GMT, Eirik Bj?rsn?s wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo found in code review. > > src/java.base/share/classes/java/lang/Record.java line 132: > >> 130: * Note that these rules imply that {@linkplain >> 131: * Double##repEquivalence representation equivalence} is used for >> 132: * the equality comparison of both for primitive floating-point > > ?of both for?? Whoops; thanks for finding that typo. Fixed in subsequent push. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27232#discussion_r2342650982 From jiangli at openjdk.org Fri Sep 12 01:08:25 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 12 Sep 2025 01:08:25 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: <6Qp-kHEVhsLq2Bdl1mmvIS2i5egm0pKkB8bjzux3iwo=.e69ceb75-06c4-45e6-a71b-2138c89c1e92@github.com> On Thu, 11 Sep 2025 00:39:43 GMT, Jiangli Zhou wrote: >> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this. > >> @magicus I'll take a look today. > > Hi @magicus I looked at your changes and focused on the launcher changes. I only looked quickly of the build changes, I think @erikj79's review is sufficient. For launcher changes, my main question is Windows platform support (for static JDK) and testing. The rest of the comments are minor. > I just realized that the testing I kicked off (tier1-5 on our internal CI) does not include running tests using the static-jdk. @jianglizhou Do you have any recommendation to the easiest way to use the static-jdk for testing? We enabled running jtreg tests on static-jdk in GHA (https://github.com/openjdk/jdk/commit/16d45511342c32ac8e8f72fb68dc21ce13339dbe). It sets `JDK_UNDER_TEST=`, `JDK_FOR_COMPILE=` and `extra-problem-lists` with .github/workflows/test.yml to run tests on static-jdk. Probably relatively easy to setup with tired testing as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3283164409 From jpai at openjdk.org Fri Sep 12 06:36:31 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 06:36:31 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v5] In-Reply-To: References: Message-ID: <3nMHANI5bOx84dbdlgPMK5jkG_dJIgQjyyKok2e6dLM=.0f6ffaa7-4ccf-4120-9869-fd10b22b15e6@github.com> > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? > > As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. > > The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. > > A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. > > tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Daniel's review - make the test othervm - merge latest from master branch - remove format() call in exception message creation - merge latest from master branch - merge latest from master branch - merge latest from master branch - add test - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25449/files - new: https://git.openjdk.org/jdk/pull/25449/files/5d6c2fdf..ca8c19a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25449&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25449&range=03-04 Stats: 8340 lines in 242 files changed: 4829 ins; 2545 del; 966 mod Patch: https://git.openjdk.org/jdk/pull/25449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25449/head:pull/25449 PR: https://git.openjdk.org/jdk/pull/25449 From jpai at openjdk.org Fri Sep 12 06:52:25 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 06:52:25 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:18:25 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - remove format() call in exception message creation >> - merge latest from master branch >> - merge latest from master branch >> - merge latest from master branch >> - add test >> - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed > > test/jdk/javax/naming/ldap/LdapClientConnTest.java line 62: > >> 60: * @library /test/lib >> 61: * @build jdk.test.lib.net.URIBuilder >> 62: * @run junit LdapClientConnTest > > Since this test creates a daemon thread and does not try to join the thread at the end it might be more prudent to run it in `/othervm` mode? Hello Daniel, good catch. It took me a while to understand this - leaving around arbitrary test specific threads in an agent VM isn't wise. You are right, making it othervm would be better. I've updated the PR to do so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25449#discussion_r2343177588 From tschatzl at openjdk.org Fri Sep 12 07:26:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 07:26:30 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 10:24:57 GMT, Andrew Haley wrote: >> I can argue I was following precedent :) I see your point though. What do you suggest to do here? Use `count` throughout instead? > >> I can argue I was following precedent :) > > You were, but it's a precedent that needs to die. > >> I see your point though. What do you suggest to do here? Use `count` throughout instead? > > Yes, although it might need a couple more comments. What do you think of https://github.com/openjdk/jdk/commit/74e9240ba275986375d3e6f0ac9bfa4b5fbb78ce ? (not committed in this branch yet because I do not want all the back-and-forth here) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2343254077 From tschatzl at openjdk.org Fri Sep 12 08:29:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 08:29:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v60] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * therealaph suggestion for avoiding the register aliasin in gen_write_ref_array_post - * walulyai review - * walulyai review * tried to remove "logged card" terminology for the current "pending card" one - * aph review, fix some comment - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 70 more: https://git.openjdk.org/jdk/compare/9e843f56...1ced9f98 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=59 Stats: 7162 lines in 112 files changed: 2594 ins; 3588 del; 980 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From mdoerr at openjdk.org Fri Sep 12 08:30:01 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 12 Sep 2025 08:30:01 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> On Fri, 12 Sep 2025 07:23:23 GMT, Thomas Schatzl wrote: >>> I can argue I was following precedent :) >> >> You were, but it's a precedent that needs to die. >> >>> I see your point though. What do you suggest to do here? Use `count` throughout instead? >> >> Yes, although it might need a couple more comments. > > What do you think of https://github.com/openjdk/jdk/commit/74e9240ba275986375d3e6f0ac9bfa4b5fbb78ce ? (not committed in this branch yet because I do not want all the back-and-forth here) Other idea: set count = noreg to prevent usage after it is used under the other name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2343415421 From rgiulietti at openjdk.org Fri Sep 12 08:55:07 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Sep 2025 08:55:07 GMT Subject: RFR: 8367382: Expand use of representation equivalence terminology [v2] In-Reply-To: References: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> Message-ID: <3NDIWydmjMwgIJOPeR9TBK7l8ruyou50zTt9pocLlOk=.a2df04dc-3272-449e-b7a8-8fc4eff47b4e@github.com> On Fri, 12 Sep 2025 00:44:38 GMT, Joe Darcy wrote: >> Small doc enhancement to use the term "representation equivalence" in a few more locations. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo found in code review. src/java.base/share/classes/java/lang/Double.java line 1462: > 1460: * @apiNote > 1461: * One idiom to implement {@linkplain > 1462: * Double##repEquivalence representation equivalence} on {@code Suggestion: * ##repEquivalence representation equivalence} on {@code for consistency with the similar change in `equals()` src/java.base/share/classes/java/lang/Float.java line 874: > 872: * returns the identical {@code int} value when applied to > 873: * each. > 874: * In other words, {@linkplain ##repEquivalence representation Suggestion: * In other words, {@linkplain Double##repEquivalence representation I think the class name is needed here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27232#discussion_r2343493915 PR Review Comment: https://git.openjdk.org/jdk/pull/27232#discussion_r2343494067 From dfuchs at openjdk.org Fri Sep 12 09:12:25 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 12 Sep 2025 09:12:25 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v5] In-Reply-To: <3nMHANI5bOx84dbdlgPMK5jkG_dJIgQjyyKok2e6dLM=.0f6ffaa7-4ccf-4120-9869-fd10b22b15e6@github.com> References: <3nMHANI5bOx84dbdlgPMK5jkG_dJIgQjyyKok2e6dLM=.0f6ffaa7-4ccf-4120-9869-fd10b22b15e6@github.com> Message-ID: On Fri, 12 Sep 2025 06:36:31 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? >> >> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. >> >> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. >> >> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Daniel's review - make the test othervm > - merge latest from master branch > - remove format() call in exception message creation > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - add test > - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25449#pullrequestreview-3215577129 From duke at openjdk.org Fri Sep 12 10:13:43 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 12 Sep 2025 10:13:43 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v7] In-Reply-To: References: Message-ID: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Fix typo. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/16f37d7f..af12dde5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From jpai at openjdk.org Fri Sep 12 10:13:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 10:13:48 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v6] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:22:27 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweaked comment. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 330: > 328: // because those nodes are already in the nodes cache. > 329: if (name.startsWith(MODULES_ROOT + "/")) { > 330: // This may preform two lookups, one for a directory (in I think this is a typo - should have been "perform"? test/jdk/jdk/internal/jimage/ImageReaderTest.java line 166: > 164: // Or module name to be empty. > 165: ":modfoo/com/foo/Alpha.class"}) > 166: public void testFindResourceNode_absent(String modAndPath) throws IOException { Hello David, for the newly introduced methods, could we also test for empty resource name? I believe the new methods should not find such a resource. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2343733831 PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2343736919 From jpai at openjdk.org Fri Sep 12 10:17:34 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 10:17:34 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v6] In-Reply-To: References: Message-ID: <03LhOECtHkZQspzIRg76NsR-oeo1MtZqXyPon2sakZQ=.4a718096-065a-452b-9efb-7e2d0dcae7f5@github.com> On Thu, 11 Sep 2025 17:22:27 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweaked comment. test/jdk/jdk/internal/jimage/ImageReaderTest.java line 150: > 148: @ValueSource(strings = { > 149: // Absolute resource names are not allowed. > 150: "modfoo:/com/bar/One.class", JUnit jupiter also has a `CsvSource` https://docs.junit.org/current/api/org.junit.jupiter.params/org/junit/jupiter/params/provider/CsvSource.html#example-heading which allows these params to be represented individually. So something like: @CsvSource ({ "modfoo", "/com/bar/One.class", "modfoo", "com/foo/Alpha.class", ... }) testFindResourceNode_absent(String module, String path) If you prefer it in the current form, that's fine too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2343748128 From jpai at openjdk.org Fri Sep 12 11:32:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 11:32:18 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). >> >> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update NPE per roger review Hello Chen, I had a look at the changes, but I'm missing some broader context of this change. The JBS issue and the PR description states that this PR is in preparation (to upcoming additional work?) to support better `NullPointerException` exception messages when some code uses `Objects.requireNonNull()`. It also talks about a `java.lang.runtime.Checks::nullCheck` method, but there's no such `java.lang.runtime.Checks` class in mainline and it appears to be a proposed class in Valhalla project (https://bugs.openjdk.org/browse/JDK-8357936). But there too it's non-existent for now. So I'll leave out the `Checks` class from this discussion. If this change were to be integrated into mainline, would there be any change to NullPointerException exception messages in any code paths? If not, then would it better to do these changes along with the `Objects.requireNonNull()` change itself, as part of https://bugs.openjdk.org/browse/JDK-8233268? In JDK-8233268, there's also a comment from Goetz proposing how the new exception message should look like. If the current changes were to be done, would it allow for that proposal to be implemented? I did have a brief look at the new jtreg test cases in this PR, but it wasn't immediately clear to me which APIs would start seeing this new proposed exception messages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3284904586 From phubner at openjdk.org Fri Sep 12 11:36:32 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 12 Sep 2025 11:36:32 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary Message-ID: Hi all, `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: 1) refactors `constantPoolOop` to be a hidden VM injected field `vmtarget` (name to be consistent with other similar cases), 2) removes `FilteredJavaFieldStream` entirely, and 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. Testing: Oracle tiers 1-3. ------------- Commit messages: - Fix typo. - Refactor to purely use injected fields. - Remove FilteredJavaFieldStream and usages. - Remove constantPoolOop from Java code. - Make constantPoolOop a hidden vmholder field. Changes: https://git.openjdk.org/jdk/pull/27209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27209&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365858 Stats: 194 lines in 9 files changed: 8 ins; 166 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27209/head:pull/27209 PR: https://git.openjdk.org/jdk/pull/27209 From duke at openjdk.org Fri Sep 12 11:46:23 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 12 Sep 2025 11:46:23 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v6] In-Reply-To: <03LhOECtHkZQspzIRg76NsR-oeo1MtZqXyPon2sakZQ=.4a718096-065a-452b-9efb-7e2d0dcae7f5@github.com> References: <03LhOECtHkZQspzIRg76NsR-oeo1MtZqXyPon2sakZQ=.4a718096-065a-452b-9efb-7e2d0dcae7f5@github.com> Message-ID: <8nsAs0DvsMNm3RXKUED-yt1YzDQxXecewLRZaoTgFH8=.d59b808f-63f7-4d6f-be08-a1694e02665c@github.com> On Fri, 12 Sep 2025 10:14:40 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweaked comment. > > test/jdk/jdk/internal/jimage/ImageReaderTest.java line 150: > >> 148: @ValueSource(strings = { >> 149: // Absolute resource names are not allowed. >> 150: "modfoo:/com/bar/One.class", > > JUnit jupiter also has a `CsvSource` https://docs.junit.org/current/api/org.junit.jupiter.params/org/junit/jupiter/params/provider/CsvSource.html#example-heading which allows these params to be represented individually. So something like: > > > @CsvSource ({ > "modfoo, /com/bar/One.class", > "modfoo, com/foo/Alpha.class", > ... > }) > testFindResourceNode_absent(String module, String path) > > > If you prefer it in the current form, that's fine too. Interesting, "CSV" is not where I'd have looked for that functionality. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2343942185 From duke at openjdk.org Fri Sep 12 11:53:20 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 12 Sep 2025 11:53:20 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v6] In-Reply-To: <8nsAs0DvsMNm3RXKUED-yt1YzDQxXecewLRZaoTgFH8=.d59b808f-63f7-4d6f-be08-a1694e02665c@github.com> References: <03LhOECtHkZQspzIRg76NsR-oeo1MtZqXyPon2sakZQ=.4a718096-065a-452b-9efb-7e2d0dcae7f5@github.com> <8nsAs0DvsMNm3RXKUED-yt1YzDQxXecewLRZaoTgFH8=.d59b808f-63f7-4d6f-be08-a1694e02665c@github.com> Message-ID: On Fri, 12 Sep 2025 11:43:25 GMT, David Beaumont wrote: >> test/jdk/jdk/internal/jimage/ImageReaderTest.java line 150: >> >>> 148: @ValueSource(strings = { >>> 149: // Absolute resource names are not allowed. >>> 150: "modfoo:/com/bar/One.class", >> >> JUnit jupiter also has a `CsvSource` https://docs.junit.org/current/api/org.junit.jupiter.params/org/junit/jupiter/params/provider/CsvSource.html#example-heading which allows these params to be represented individually. So something like: >> >> >> @CsvSource ({ >> "modfoo, /com/bar/One.class", >> "modfoo, com/foo/Alpha.class", >> ... >> }) >> testFindResourceNode_absent(String module, String path) >> >> >> If you prefer it in the current form, that's fine too. > > Interesting, "CSV" is not where I'd have looked for that functionality. Hmm, that syntax doesn't work for me. org.junit.jupiter.api.extension.ParameterResolutionException: No ParameterResolver registered for parameter [java.lang.String arg1] in method [public void ImageReaderTest.testResourceNodes_present(java.lang.String,java.lang.String) throws java.io.IOException]. I'll just add the empty path case and leave it at that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2343983393 From jpai at openjdk.org Fri Sep 12 11:57:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 11:57:14 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v6] In-Reply-To: References: <03LhOECtHkZQspzIRg76NsR-oeo1MtZqXyPon2sakZQ=.4a718096-065a-452b-9efb-7e2d0dcae7f5@github.com> <8nsAs0DvsMNm3RXKUED-yt1YzDQxXecewLRZaoTgFH8=.d59b808f-63f7-4d6f-be08-a1694e02665c@github.com> Message-ID: <_BD6D9H90GqlojnMzm-2LJI_wBdr-AwOXVCsHoDFulc=.a385a437-e810-4c18-8e99-fa99800f2986@github.com> On Fri, 12 Sep 2025 11:50:16 GMT, David Beaumont wrote: > I'll just add the empty path case and leave it at that. That's fine with me. More as a FYI though - I had a typo in my original CsvSource comment/example, which I later modified. So I don't know if that is what is causing this error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2344003663 From amitkumar at openjdk.org Fri Sep 12 11:57:29 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 12 Sep 2025 11:57:29 GMT Subject: Withdrawn: 8366495: Incorrect minimum memory size allocated in allocateNativeInternal() In-Reply-To: References: Message-ID: <2b_wfnUQCfcfMEOdOlgezwW4pkAhP9uP9NSTMRN9vag=.781d914f-1629-4132-a4f2-3619949d0367@github.com> On Mon, 1 Sep 2025 05:31:43 GMT, Amit Kumar wrote: > Originally Reported in OpenJ9, fix by @AditiS11 present here: https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/32 > > These test failure were reported in OpenJ9 (x86), I can't reproduce on my system (s390x): > > java/foreign/TestFill.java > java/foreign/TestSegments.java > java/foreign/TestSegmentBulkOperationsContentHash.java > java/foreign/TestStringEncoding.java > java/foreign/TestVarArgs.java > > > > ```java > // Always allocate at least some memory so that zero-length segments have distinct > // non-zero addresses. > alignedSize = Math.max(1, alignedSize); > > > Here minimum-allocated size will be 1, which is incorrect because > > > private static void initNativeMemory(long address, long byteSize) { > for (long i = 0; i < byteSize; i += Long.BYTES) { > UNSAFE.putLongUnaligned(null, address + i, 0); > } > } > > `initNativeMemory()` is going to write Long. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27027 From duke at openjdk.org Fri Sep 12 12:02:20 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 12 Sep 2025 12:02:20 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v6] In-Reply-To: <_BD6D9H90GqlojnMzm-2LJI_wBdr-AwOXVCsHoDFulc=.a385a437-e810-4c18-8e99-fa99800f2986@github.com> References: <03LhOECtHkZQspzIRg76NsR-oeo1MtZqXyPon2sakZQ=.4a718096-065a-452b-9efb-7e2d0dcae7f5@github.com> <8nsAs0DvsMNm3RXKUED-yt1YzDQxXecewLRZaoTgFH8=.d59b808f-63f7-4d6f-be08-a1694e02665c@github.com> <_BD6D9H90GqlojnMzm-2LJI_wBdr-AwOXVCsHoDFulc=.a385a437-e810-4c18-8e99-fa99800f2986@github.com> Message-ID: On Fri, 12 Sep 2025 11:54:40 GMT, Jaikiran Pai wrote: >> Hmm, that syntax doesn't work for me. >> >> org.junit.jupiter.api.extension.ParameterResolutionException: No ParameterResolver registered for parameter [java.lang.String arg1] in method [public void ImageReaderTest.testResourceNodes_present(java.lang.String,java.lang.String) throws java.io.IOException]. >> >> >> I'll just add the empty path case and leave it at that. > >> I'll just add the empty path case and leave it at that. > > That's fine with me. More as a FYI though - I had a typo in my original CsvSource comment/example, which I later modified. So I don't know if that is what is causing this error. Ahh, it's all one value per pair. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2344018785 From duke at openjdk.org Fri Sep 12 12:08:35 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 12 Sep 2025 12:08:35 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: Message-ID: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Tweak test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/af12dde5..e2ead2a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=06-07 Stats: 16 lines in 1 file changed: 2 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From aefimov at openjdk.org Fri Sep 12 13:33:19 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 12 Sep 2025 13:33:19 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v17] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:08:20 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 656 commits: > > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - Simplify control flow > - Remove unnecessary instanceof checks > - Use IntFunction for header generator > - ... and 646 more: https://git.openjdk.org/jdk/compare/5cd7721a...9acc3590 Marked as reviewed by aefimov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3216731618 From aefimov at openjdk.org Fri Sep 12 14:46:21 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 12 Sep 2025 14:46:21 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v5] In-Reply-To: <3nMHANI5bOx84dbdlgPMK5jkG_dJIgQjyyKok2e6dLM=.0f6ffaa7-4ccf-4120-9869-fd10b22b15e6@github.com> References: <3nMHANI5bOx84dbdlgPMK5jkG_dJIgQjyyKok2e6dLM=.0f6ffaa7-4ccf-4120-9869-fd10b22b15e6@github.com> Message-ID: On Fri, 12 Sep 2025 06:36:31 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? >> >> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. >> >> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. >> >> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Daniel's review - make the test othervm > - merge latest from master branch > - remove format() call in exception message creation > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - add test > - 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed Hello Jaikiran, The fix and its logic looks correct to me. I have a couple of suggestions regarding the new test: 1. The test can be modified to remove the dependency on the internal `LdapCtx` class. Something like: @@ -43,11 +43,14 @@ import java.util.concurrent.Future; import java.util.concurrent.atomic.AtomicInteger; -import com.sun.jndi.ldap.LdapCtx; import jdk.test.lib.net.URIBuilder; import org.junit.jupiter.api.AfterAll; import org.junit.jupiter.api.BeforeAll; import org.junit.jupiter.api.Test; + +import javax.naming.Context; +import javax.naming.InitialContext; + import static java.nio.charset.StandardCharsets.US_ASCII; import static org.junit.jupiter.api.Assertions.fail; @@ -56,7 +59,6 @@ * @bug 8357708 * @summary verify that com.sun.jndi.ldap.Connection does not ignore the LDAP replies * that were received before the Connection was closed. - * @modules java.naming/com.sun.jndi.ldap * @library /test/lib * @build jdk.test.lib.net.URIBuilder * @run junit/othervm LdapClientConnTest @@ -381,17 +383,22 @@ @Override public Void call() throws Exception { - LdapCtx ldapCtx = null; + Context ldapCtx = null; try { final InetSocketAddress serverAddr = server.getAddress(); final Hashtable envProps = new Hashtable<>(); // explicitly set LDAP version to 3 to prevent LDAP BIND requests // during LdapCtx instantiation envProps.put("java.naming.ldap.version", "3"); - ldapCtx = new LdapCtx("", - serverAddr.getAddress().getHostAddress(), - serverAddr.getPort(), - envProps, false); + envProps.put(Context.INITIAL_CONTEXT_FACTORY, + "com.sun.jndi.ldap.LdapCtxFactory"); + String providerUrl = URIBuilder.newBuilder() + .scheme("ldap") + .host(serverAddr.getAddress()) + .port(serverAddr.getPort()) + .build().toString(); + envProps.put(Context.PROVIDER_URL, providerUrl); + ldapCtx = new InitialContext(envProps); final String name = SEARCH_REQ_DN_PREFIX + taskName + SEARCH_REQ_DN_SUFFIX; // trigger the LDAP SEARCH requests through the lookup call. we are not // interested in the returned value and are merely interested in a normal 2. Maybe move the new test to the `test/jdk/com/sun/jndi/ldap` folder where other tests for internal LDAP classes live. 3. I like the dynamic approach on generating and parsing the LDAP messages. For future tests in JNDI/LDAP area such approach could be beneficial. Therefore, a suggestion - move `private static final byte BER_TYPE_*` constants to the `test/jdk/com/sun/jndi/ldap/lib/LDAPTestUtils.java`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25449#issuecomment-3285576752 From ghan at openjdk.org Fri Sep 12 14:49:17 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 12 Sep 2025 14:49:17 GMT Subject: Integrated: 8328874: Class::forName0 should validate the class name length early In-Reply-To: References: Message-ID: On Fri, 15 Aug 2025 15:19:35 GMT, Guanqiang Han wrote: > Validate class name length immediately after GetStringUTFLength() in Class.forName0. This prevents potential issues caused by overly long class names before they reach later code that would reject them, throwing ClassNotFoundException early. This pull request has now been integrated. Changeset: 44aad078 Author: Guanqiang Han Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/44aad0786bc85e11eded1da4cf4eb96698424c8b Stats: 131 lines in 4 files changed: 127 ins; 0 del; 4 mod 8328874: Class::forName0 should validate the class name length early Reviewed-by: rriggs, liach, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26802 From jpai at openjdk.org Fri Sep 12 15:04:20 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 15:04:20 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 12:08:35 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweak test. test/jdk/jdk/internal/jimage/ImageReaderTest.java line 163: > 161: // Or module names/paths to be empty. > 162: "'':modfoo/com/foo/Alpha.class", > 163: "modfoo:''"}) Does the use of `'` literals in that string translate to an empty value for module/resource path? I haven't checked myself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2344520343 From jpai at openjdk.org Fri Sep 12 15:09:19 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 15:09:19 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 12:08:35 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweak test. Thank you for the updates. The changes look OK to me. My knowledge of this area is very limited, so please wait for additional reviews from others familiar with this area before integrating. It would be good to verify that tier1, tier2 and tier3 tests continue to pass with these changes. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27203#pullrequestreview-3217167651 From duke at openjdk.org Fri Sep 12 15:09:20 2025 From: duke at openjdk.org (David Beaumont) Date: Fri, 12 Sep 2025 15:09:20 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 12:08:35 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweak test. Tests already verified. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27203#issuecomment-3285656239 From alanb at openjdk.org Fri Sep 12 15:45:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Sep 2025 15:45:15 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: Message-ID: <_Ody3y1l61hto2Y_z1BMNTExSwlPzgCM5gu1ikfUEtU=.b3c45c52-7f7e-46e2-b697-d324d12ee15a@github.com> On Fri, 12 Sep 2025 12:08:35 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweak test. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 360: > 358: // underlying jimage, but can only reliably return resource nodes. > 359: if (moduleName.indexOf('/') >= 0) { > 360: return null; Can you explain this further? We can't have a "/' in the module name at the language or API level. We could at the class level but there is likely a lot of work required in jimage, jlink and elsewhere if we ever allowed "/" in a module name. So right now, it would be a IAE if a call if invoking this with a "/" in the module name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2344648666 From alanb at openjdk.org Fri Sep 12 15:52:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Sep 2025 15:52:13 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: Message-ID: <2LFahCvR7vDtTC9YVY55btRZRcTkFhfZvtX8-8IKk3Q=.8745c348-3ed3-46d4-a846-3c5adbe45c1d@github.com> On Fri, 12 Sep 2025 12:08:35 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Tweak test. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 381: > 379: /** Returns whether a resource exists in the given module. */ > 380: boolean containsResource(String moduleName, String resourcePath) { > 381: // This method is tuned for cases where resources are likely to NOT I think this sentence can move to the method description. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2344661041 From jpai at openjdk.org Fri Sep 12 16:04:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 16:04:59 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v6] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? > > As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. > > The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. > > A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. > > tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - move the new test under test/jdk/com/sun/jndi/ldap - Aleksei's review - use public/standard APIs instead of internal com.sun.jndi.ldap.LdapCtx ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25449/files - new: https://git.openjdk.org/jdk/pull/25449/files/ca8c19a8..c5a222ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25449&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25449&range=04-05 Stats: 16 lines in 1 file changed: 9 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25449/head:pull/25449 PR: https://git.openjdk.org/jdk/pull/25449 From jpai at openjdk.org Fri Sep 12 16:16:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 16:16:14 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v6] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 16:04:59 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? >> >> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. >> >> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. >> >> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - move the new test under test/jdk/com/sun/jndi/ldap > - Aleksei's review - use public/standard APIs instead of internal com.sun.jndi.ldap.LdapCtx Hello Aleksei, I have updated the PR to implement your suggestion 1 and 2. As for the other suggestion of moving these constants to the `LDAPTestUtils` test library class, I think that's a good idea too. However, I gave that a try and that isn't straightforward. Once I move them to that class, jtreg then requires me to add a `@build` and a `@library` instruction to bring in the `test.LDAPServer` class which the `LDAPTestUtils` uses (but not this new test). That wouldn't be too bad and I did add those, but then `LDAPTestUtils` has an import of an internal class: import com.sun.jndi.ldap.LdapURL so that then forces me to reintroduce the: @modules java.naming/com.sun.jndi.ldap in this new test, which I think defeats the entire cleanup. So I decided to leave those constants this in this test class for now and reconsider that move as a future work. Would that be OK? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25449#issuecomment-3285898790 From aefimov at openjdk.org Fri Sep 12 16:22:22 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 12 Sep 2025 16:22:22 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v6] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 16:04:59 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? >> >> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. >> >> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. >> >> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - move the new test under test/jdk/com/sun/jndi/ldap > - Aleksei's review - use public/standard APIs instead of internal com.sun.jndi.ldap.LdapCtx Looks good to me! ------------- Marked as reviewed by aefimov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25449#pullrequestreview-3217658193 From aefimov at openjdk.org Fri Sep 12 16:22:23 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 12 Sep 2025 16:22:23 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v6] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 16:13:30 GMT, Jaikiran Pai wrote: > Hello Aleksei, I have updated the PR to implement your suggestion 1 and 2. As for the other suggestion of moving these constants to the `LDAPTestUtils` test library class, I think that's a good idea too. However, I gave that a try and that isn't straightforward. Once I move them to that class, jtreg then requires me to add a `@build` and a `@library` instruction to bring in the `test.LDAPServer` class which the `LDAPTestUtils` uses (but not this new test). That wouldn't be too bad and I did add those, but then `LDAPTestUtils` has an import of an internal class: > > ``` > import com.sun.jndi.ldap.LdapURL > ``` > > so that then forces me to reintroduce the: > > ``` > @modules java.naming/com.sun.jndi.ldap > ``` > > in this new test, which I think defeats the entire cleanup. So I decided to leave those constants this in this test class for now and reconsider that move as a future work. Would that be OK? Oh, it is complicated, thank you for trying to move the constants. I agree that it defeats the entire cleanup initiative and doesn't worth the effort. It is OK to leave the constants in the test class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25449#issuecomment-3285926413 From jpai at openjdk.org Fri Sep 12 16:32:21 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 16:32:21 GMT Subject: RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v6] In-Reply-To: References: Message-ID: <5IzreIZ2GmT8VbshpaiVW0BL9mYSzPlIwjC_00DeTD0=.b3cd3d76-6e43-4ca4-b6a8-720940a6bb88@github.com> On Fri, 12 Sep 2025 16:04:59 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? >> >> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. >> >> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. >> >> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. >> >> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - move the new test under test/jdk/com/sun/jndi/ldap > - Aleksei's review - use public/standard APIs instead of internal com.sun.jndi.ldap.LdapCtx Thank you everyone for the reviews. I've triggered a CI run with these latest changes and when that completes I'll go ahead and integrate this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25449#issuecomment-3285976515 From liach at openjdk.org Fri Sep 12 19:14:27 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Sep 2025 19:14:27 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:28:41 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update NPE per roger review > > Hello Chen, I had a look at the changes, but I'm missing some broader context of this change. > > The JBS issue and the PR description states that this PR is in preparation (to upcoming additional work?) to support better `NullPointerException` exception messages when some code uses `Objects.requireNonNull()`. It also talks about a `java.lang.runtime.Checks::nullCheck` method, but there's no such `java.lang.runtime.Checks` class in mainline and it appears to be a proposed class in Valhalla project (https://bugs.openjdk.org/browse/JDK-8357936). But there too it's non-existent for now. So I'll leave out the `Checks` class from this discussion. > > If this change were to be integrated into mainline, would there be any change to NullPointerException exception messages in any code paths? If not, then would it better to do these changes along with the `Objects.requireNonNull()` change itself, as part of https://bugs.openjdk.org/browse/JDK-8233268? In JDK-8233268, there's also a comment from Goetz proposing how the new exception message should look like. If the current changes were to be done, would it allow for that proposal to be implemented? > > I did have a brief look at the new jtreg test cases in this PR, but it wasn't immediately clear to me which APIs would start seeing this new proposed exception messages. Hi @jaikiran, this is currently neutral to mainline. I split the actual Objects.rNN changes because they have to go through CSR reviews. The actual change to hook it up was removed in https://github.com/openjdk/jdk/pull/26600/commits/39c2d16fa98276319d18cf9334e1e9c794e56779. The message is not the same as what Goetz Lindenmaier proposed, in part because the information about the source of the exception is already obvious in the stack traces (top level is always the null check API). I decided to only include which slot had null instead. In the test suite, the new API to see the proposed new exception messages would be `NullCheckAPITest::nullCheck`. This demonstrates the flexibility of this new system I added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3286532403 From asemenyuk at openjdk.org Fri Sep 12 20:55:28 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 12 Sep 2025 20:55:28 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows Message-ID: Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. ------------- Commit messages: - 8365790: Shutdown hook for application image does not work on Windows Changes: https://git.openjdk.org/jdk/pull/27264/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365790 Stats: 269 lines in 6 files changed: 266 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27264/head:pull/27264 PR: https://git.openjdk.org/jdk/pull/27264 From asemenyuk at openjdk.org Fri Sep 12 21:02:45 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 12 Sep 2025 21:02:45 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v2] In-Reply-To: References: Message-ID: > Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: - Hide powershell console - Add extra assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27264/files - new: https://git.openjdk.org/jdk/pull/27264/files/4464486f..df6d8318 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27264/head:pull/27264 PR: https://git.openjdk.org/jdk/pull/27264 From jlu at openjdk.org Fri Sep 12 21:13:16 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Sep 2025 21:13:16 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v2] In-Reply-To: <9fwe7YcFQM19gM4JMrH92REwpKxbdVjChQGZdkgjPk8=.3fc0b5d0-7248-4fc8-8a47-7ad692073076@github.com> References: <9fwe7YcFQM19gM4JMrH92REwpKxbdVjChQGZdkgjPk8=.3fc0b5d0-7248-4fc8-8a47-7ad692073076@github.com> Message-ID: On Wed, 10 Sep 2025 23:54:31 GMT, Johannes Graham wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 4184: >> >>> 4182: >>> 4183: if (fitsIntoLong()) { >>> 4184: return Long.toString(longValue(), radix); >> >> We may want to consider separating this `BigInteger` fast path from this PR/change, since it is independent of the speedup in the `DigitList` changes. Others may not have a problem with it though, so maybe we can wait and see what they say. > > Without the fast-path, there was a performance drop with the "small" BigDecimals (from memory about 10%). That's what drove me to tinker with `BigInteger.toString`. But if this one can stand on its own, despite the perf drop, I'm happy to separate out the BigInteger part. I'll generate some new perf numbers after the Level.Invocation fix. OK understood. I think we would only want to go through with this PR if we could avoid that perf regression in the _DefFormatterBench.testSmallBigDecDefNumberFormatter_ case. So either including this BI fast path as part of this change, or (if there are scope concerns), making a separate change for it first and making this PR dependent on it seems reasonable to me. It would be good to get @rgiulietti's opinion on this. I think it would also be good to include the _java.math.BigIntegers_ results since this change directly impacts those results as well. (Which look to have sizeable improvements for _BigIntegers.testSmallToString_ and _BigIntegers.testLargeToString_.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2345424936 From jlu at openjdk.org Fri Sep 12 21:13:19 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Sep 2025 21:13:19 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v2] In-Reply-To: <_ZwF0CJ0mY-x-ie19mhkUiTnLlBlDBG6-zCzKaLfbyU=.e8f9d819-d67b-4b31-b19c-3369c69da5ef@github.com> References: <_ZwF0CJ0mY-x-ie19mhkUiTnLlBlDBG6-zCzKaLfbyU=.e8f9d819-d67b-4b31-b19c-3369c69da5ef@github.com> Message-ID: On Wed, 10 Sep 2025 23:47:47 GMT, Johannes Graham wrote: >> When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. >> >> This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. > > Johannes Graham has updated the pull request incrementally with two additional commits since the last revision: > > - use Level.Invocation > - review fixes test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 86: > 84: > 85: @Benchmark > 86: @OperationsPerInvocation(13) Now that we are reusing 13 multiple times, we can replace such occurrences with a constant. `VALUES_SIZE`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2345116810 From darcy at openjdk.org Fri Sep 12 22:06:58 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 12 Sep 2025 22:06:58 GMT Subject: RFR: 8367382: Expand use of representation equivalence terminology [v3] In-Reply-To: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> References: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> Message-ID: > Small doc enhancement to use the term "representation equivalence" in a few more locations. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27232/files - new: https://git.openjdk.org/jdk/pull/27232/files/5c7c92b6..1a327d96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27232&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27232&range=01-02 Stats: 6 lines in 2 files changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27232/head:pull/27232 PR: https://git.openjdk.org/jdk/pull/27232 From darcy at openjdk.org Fri Sep 12 22:07:02 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 12 Sep 2025 22:07:02 GMT Subject: RFR: 8367382: Expand use of representation equivalence terminology [v2] In-Reply-To: <3NDIWydmjMwgIJOPeR9TBK7l8ruyou50zTt9pocLlOk=.a2df04dc-3272-449e-b7a8-8fc4eff47b4e@github.com> References: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> <3NDIWydmjMwgIJOPeR9TBK7l8ruyou50zTt9pocLlOk=.a2df04dc-3272-449e-b7a8-8fc4eff47b4e@github.com> Message-ID: On Fri, 12 Sep 2025 08:51:22 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo found in code review. > > src/java.base/share/classes/java/lang/Float.java line 874: > >> 872: * returns the identical {@code int} value when applied to >> 873: * each. >> 874: * In other words, {@linkplain ##repEquivalence representation > > Suggestion: > > * In other words, {@linkplain Double##repEquivalence representation > > I think the class name is needed here. Correct and fixed. (I though the javac/javadoc doctlint checks should catch that kind of problem, but apparently not.) Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27232#discussion_r2345511287 From duke at openjdk.org Fri Sep 12 22:44:54 2025 From: duke at openjdk.org (Johannes Graham) Date: Fri, 12 Sep 2025 22:44:54 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v3] In-Reply-To: References: Message-ID: <88vSo4iHwx47hKJ2whkClMWAP5xunklbIH2StcsGTlM=.83f9e6aa-ecaf-4455-86c2-7b6c8f370517@github.com> > When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. > > This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: VALUES_SIZE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27118/files - new: https://git.openjdk.org/jdk/pull/27118/files/6865fe6a..47eb0a89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27118&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27118&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27118.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27118/head:pull/27118 PR: https://git.openjdk.org/jdk/pull/27118 From duke at openjdk.org Fri Sep 12 23:01:17 2025 From: duke at openjdk.org (Johannes Graham) Date: Fri, 12 Sep 2025 23:01:17 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v3] In-Reply-To: <88vSo4iHwx47hKJ2whkClMWAP5xunklbIH2StcsGTlM=.83f9e6aa-ecaf-4455-86c2-7b6c8f370517@github.com> References: <88vSo4iHwx47hKJ2whkClMWAP5xunklbIH2StcsGTlM=.83f9e6aa-ecaf-4455-86c2-7b6c8f370517@github.com> Message-ID: On Fri, 12 Sep 2025 22:44:54 GMT, Johannes Graham wrote: >> When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. >> >> This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. > > Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: > > VALUES_SIZE BigIntegers benchmark Baseline Benchmark Mode Cnt Score Error Units BigIntegers.testHugeToString avgt 15 96.249 ? 3.766 ns/op BigIntegers.testLargeToString avgt 15 19.919 ? 0.532 ns/op BigIntegers.testSmallToString avgt 15 28.000 ? 1.132 ns/op This PR (fast-path in BigInteger.toString) BigIntegers.testHugeToString avgt 15 95.965 ? 1.563 ns/op BigIntegers.testLargeToString avgt 15 7.701 ? 0.083 ns/op BigIntegers.testSmallToString avgt 15 7.027 ? 0.380 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3287050561 From almatvee at openjdk.org Sat Sep 13 01:20:21 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 13 Sep 2025 01:20:21 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:02:45 GMT, Alexey Semenyuk wrote: >> Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. > > Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: > > - Hide powershell console > - Add extra assert Looks good. I assume parent process will terminate as well after child process? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27264#issuecomment-3287327229 From jpai at openjdk.org Sat Sep 13 02:06:34 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 02:06:34 GMT Subject: Integrated: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed In-Reply-To: References: Message-ID: On Mon, 26 May 2025 12:28:16 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708? > > As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen. > > The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`. > > A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces. > > tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25. This pull request has now been integrated. Changeset: e2eaa2ec Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/e2eaa2ecf39f1746481bfdd603e84167c886545b Stats: 541 lines in 3 files changed: 446 ins; 60 del; 35 mod 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed Co-authored-by: Aleksei Efimov Reviewed-by: aefimov, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/25449 From asemenyuk at openjdk.org Sat Sep 13 03:24:13 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 13 Sep 2025 03:24:13 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:02:45 GMT, Alexey Semenyuk wrote: >> Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. > > Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: > > - Hide powershell console > - Add extra assert Thank you for the review. The child process will automatically terminate when the parent terminates and vice versa. The fix disables Ctrl+C event handling in the parent process to let the child process handle it. When a Ctrl+C event occurs, the child process running the JVM terminates, automatically terminating the parent process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27264#issuecomment-3287432485 From jpai at openjdk.org Sat Sep 13 07:17:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 07:17:50 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null Message-ID: Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. ------------- Commit messages: - 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null Changes: https://git.openjdk.org/jdk/pull/27270/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27270&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367597 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27270.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27270/head:pull/27270 PR: https://git.openjdk.org/jdk/pull/27270 From alanb at openjdk.org Sat Sep 13 07:28:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Sep 2025 07:28:11 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 07:10:42 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? > > As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. > > The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. > > tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. src/java.base/share/classes/java/lang/Shutdown.java line 177: > 175: private static void logRuntimeExit(int status) { > 176: try { > 177: if (!VM.isBooted()) { Can you move it to the top of the method so that the isBooted check isn't in the try-catch block? isBooted shouldn't throw but if it did then we wouldn't want the logging exception handler running. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27270#discussion_r2345997129 From jpai at openjdk.org Sat Sep 13 07:36:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 07:36:50 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v2] In-Reply-To: References: Message-ID: <40FaZkpAKGElJrAlpsayZVzqb2LeWWn5SOghPcMoraY=.5e74bd61-f465-4c39-828d-1c8e532a78f8@github.com> > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? > > As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. > > The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. > > tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alan's review - move the VM.isBooted() check outside try block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27270/files - new: https://git.openjdk.org/jdk/pull/27270/files/658a59e6..993845cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27270&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27270&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27270.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27270/head:pull/27270 PR: https://git.openjdk.org/jdk/pull/27270 From alanb at openjdk.org Sat Sep 13 07:36:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Sep 2025 07:36:50 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v2] In-Reply-To: <40FaZkpAKGElJrAlpsayZVzqb2LeWWn5SOghPcMoraY=.5e74bd61-f465-4c39-828d-1c8e532a78f8@github.com> References: <40FaZkpAKGElJrAlpsayZVzqb2LeWWn5SOghPcMoraY=.5e74bd61-f465-4c39-828d-1c8e532a78f8@github.com> Message-ID: On Sat, 13 Sep 2025 07:33:50 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. >> >> The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. >> >> tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's review - move the VM.isBooted() check outside try block Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27270#pullrequestreview-3219825604 From jpai at openjdk.org Sat Sep 13 07:36:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 07:36:50 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v2] In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 07:25:50 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan's review - move the VM.isBooted() check outside try block > > src/java.base/share/classes/java/lang/Shutdown.java line 177: > >> 175: private static void logRuntimeExit(int status) { >> 176: try { >> 177: if (!VM.isBooted()) { > > Can you move it to the top of the method so that the isBooted check isn't in the try-catch block? isBooted shouldn't throw but if it did then we wouldn't want the logging exception handler running. Done - I've updated the PR with this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27270#discussion_r2346009597 From alanb at openjdk.org Sat Sep 13 08:51:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Sep 2025 08:51:09 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v2] In-Reply-To: <40FaZkpAKGElJrAlpsayZVzqb2LeWWn5SOghPcMoraY=.5e74bd61-f465-4c39-828d-1c8e532a78f8@github.com> References: <40FaZkpAKGElJrAlpsayZVzqb2LeWWn5SOghPcMoraY=.5e74bd61-f465-4c39-828d-1c8e532a78f8@github.com> Message-ID: On Sat, 13 Sep 2025 07:36:50 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. >> >> The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. >> >> tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's review - move the VM.isBooted() check outside try block On second thoughts, Shutdown.exit might be better place, meaning only attempt to log if the VM is full initialized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27270#issuecomment-3287825828 From jpai at openjdk.org Sat Sep 13 09:35:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 09:35:54 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? > > As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. > > The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. > > tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: move the check to Shutdown.exit() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27270/files - new: https://git.openjdk.org/jdk/pull/27270/files/993845cd..af6acf5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27270&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27270&range=01-02 Stats: 8 lines in 1 file changed: 2 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27270.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27270/head:pull/27270 PR: https://git.openjdk.org/jdk/pull/27270 From jpai at openjdk.org Sat Sep 13 09:35:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Sep 2025 09:35:54 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v2] In-Reply-To: References: <40FaZkpAKGElJrAlpsayZVzqb2LeWWn5SOghPcMoraY=.5e74bd61-f465-4c39-828d-1c8e532a78f8@github.com> Message-ID: On Sat, 13 Sep 2025 08:47:21 GMT, Alan Bateman wrote: > On second thoughts, Shutdown.exit might be better place, meaning only attempt to log if the VM is full initialized. That's fine too. Right now `logRuntimeExit()` is only invoked from `Shutdown.exit()` and I don't expect additional places calling this method anytime soon in future. If at all we start calling that method from other places, we can move the check within the `logRuntimeExit()` method. So I've updated the PR as per your suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27270#issuecomment-3287914673 From duke at openjdk.org Sat Sep 13 09:48:23 2025 From: duke at openjdk.org (duke) Date: Sat, 13 Sep 2025 09:48:23 GMT Subject: Withdrawn: 8357728: Optimize Executable#synthesizeAllParams In-Reply-To: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com> References: <0qVgwcVSAYKsWc8eNHuDThScC9vz4OCxSdA_Am9ENAo=.f9d422f8-2d4a-4244-9d74-7b605df2cdd5@github.com> Message-ID: On Tue, 24 Jun 2025 22:32:30 GMT, Chen Liang wrote: > Currently, fake parameters are created with "arg0" etc. strings that are retained for class file methods with no MethodParameters attribute. The original issue report observes many of these strings present in the heap. To address this issue, we can remove these eagerly created fake names, bringing their behavior in line with nameless parameters from MethodParameters attribute, such as those from inner class constructors. A unit test verifies that no name is retained in the Parameter object when the name is fake. > > The original report recommends using a pool to store the arg name strings. I did not take that approach as I don't think it is very necessary; if the issue of retained fake names persist, we can update `Parameter::getName` to return fake names from a pool instead. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25961 From rgiulietti at openjdk.org Sat Sep 13 10:24:11 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Sat, 13 Sep 2025 10:24:11 GMT Subject: RFR: 8367382: Expand use of representation equivalence terminology [v3] In-Reply-To: References: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> Message-ID: On Fri, 12 Sep 2025 22:06:58 GMT, Joe Darcy wrote: >> Small doc enhancement to use the term "representation equivalence" in a few more locations. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27232#pullrequestreview-3220242364 From almatvee at openjdk.org Sat Sep 13 20:06:09 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 13 Sep 2025 20:06:09 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:02:45 GMT, Alexey Semenyuk wrote: >> Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. > > Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: > > - Hide powershell console > - Add extra assert Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27264#pullrequestreview-3221316305 From duke at openjdk.org Sat Sep 13 21:19:18 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 13 Sep 2025 21:19:18 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal Message-ID: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> 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_decimali.pdf) ------------- 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 From duke at openjdk.org Sat Sep 13 21:53:53 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 13 Sep 2025 21:53:53 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v2] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. > [Here is a proof for the formula.](https://github.com/user-attachments/files/22314648/frazioni_decimali.pdf) fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Refine comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/1d26f0e2..41f6ef9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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 From duke at openjdk.org Sat Sep 13 21:58:52 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 13 Sep 2025 21:58:52 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v3] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: <-WBXU5SahoMqMskypMFbWdlJpCmPlR6x1rtEdQCbfP0=.794bd0d1-9f38-49c7-b08a-2bd0126d887a@github.com> > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. > [Here is a proof for the formula.](https://github.com/user-attachments/files/22314648/frazioni_decimali.pdf) fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Refine comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/41f6ef9e..e4012044 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From duke at openjdk.org Sat Sep 13 22:13:00 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 13 Sep 2025 22:13:00 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v4] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. > [Here is a proof for the formula.](https://github.com/user-attachments/files/22314648/frazioni_decimali.pdf) fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Refine comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/e4012044..4b1f98f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From duke at openjdk.org Sat Sep 13 22:31:19 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 13 Sep 2025 22:31:19 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v5] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. > [Here is a proof for the formula.](https://github.com/user-attachments/files/22314648/frazioni_decimali.pdf) fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Avoid overflow of precision ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/4b1f98f3..b3e985c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 From swen at openjdk.org Sun Sep 14 04:59:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 14 Sep 2025 04:59:18 GMT Subject: RFR: 8367324: Avoid redundant parsing when formatting with DigitList [v3] In-Reply-To: <88vSo4iHwx47hKJ2whkClMWAP5xunklbIH2StcsGTlM=.83f9e6aa-ecaf-4455-86c2-7b6c8f370517@github.com> References: <88vSo4iHwx47hKJ2whkClMWAP5xunklbIH2StcsGTlM=.83f9e6aa-ecaf-4455-86c2-7b6c8f370517@github.com> Message-ID: On Fri, 12 Sep 2025 22:44:54 GMT, Johannes Graham wrote: >> When formatting doubles or BigDecimals, DigitList first formats them as a string and then parses the resultant string to extract the mantissa and the exponent. This can be done more directly. This allows removing some parsing code and removes a cached byte array. >> >> This also facilitates potential cleanups in FloatingDecimal (removal of getChars method) but I've left that for later to minimize conflicts with other changes there. > > Johannes Graham has updated the pull request incrementally with one additional commit since the last revision: > > VALUES_SIZE src/java.base/share/classes/java/text/DigitList.java line 732: > 730: > 731: // The digit part of -9223372036854775808L > 732: private static final byte[] LONG_MIN_REP = "9223372036854775808".getBytes(StandardCharsets.ISO_8859_1); add `@Stable` here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27118#discussion_r2347120493 From duke at openjdk.org Sun Sep 14 08:42:53 2025 From: duke at openjdk.org (jonghoonpark) Date: Sun, 14 Sep 2025 08:42:53 GMT Subject: RFR: 8364927: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib Message-ID: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 --- Following the direction outlined in the issue description, I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. I've confirmed that it works without issues in my local tests. Reviews and feedback are welcome. ------------- Commit messages: - Refactor: Introduce SmapsParser Changes: https://git.openjdk.org/jdk/pull/27273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364927 Stats: 459 lines in 3 files changed: 234 ins; 212 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27273/head:pull/27273 PR: https://git.openjdk.org/jdk/pull/27273 From duke at openjdk.org Sun Sep 14 10:02:45 2025 From: duke at openjdk.org (jonghoonpark) Date: Sun, 14 Sep 2025 10:02:45 GMT Subject: RFR: 8364927: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib [v2] In-Reply-To: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> Message-ID: <7KPVHAnRl-SW1Bg0tFf5CcIkYf0XYlhrwwWFXXi-jYk=.9fe16f05-9689-4eb4-8bdc-3a72eca3a4df@github.com> > related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 > > --- > > Following the direction outlined in the issue description, > I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. > > I've confirmed that it works without issues in my local tests. > > Reviews and feedback are welcome. jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Refactor: Introduce SmapsParser Signed-off-by: jonghoonpark ------------- Changes: https://git.openjdk.org/jdk/pull/27273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27273&range=01 Stats: 491 lines in 3 files changed: 237 ins; 243 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27273/head:pull/27273 PR: https://git.openjdk.org/jdk/pull/27273 From duke at openjdk.org Sun Sep 14 10:02:46 2025 From: duke at openjdk.org (jonghoonpark) Date: Sun, 14 Sep 2025 10:02:46 GMT Subject: RFR: 8364927: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib In-Reply-To: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> Message-ID: On Sun, 14 Sep 2025 08:35:53 GMT, jonghoonpark wrote: > related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 > > --- > > Following the direction outlined in the issue description, > I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. > > I've confirmed that it works without issues in my local tests. > > Reviews and feedback are welcome. I converted this PR to a draft due to changes in https://github.com/openjdk/jdk/pull/27143 have confirmed that both `TestTracePageSizes` and `TestTransparentHugePagesHeap` pass when tested locally. Additionally, I verified that `TestTransparentHugePagesHeap` also passes without any issues when the `-XX:+UseCompressedOops` option is added, as shown below: OutputAnalyzer oa = ProcessTools.executeTestJava("-XX:+Use" + args[0] + "GC", "-Xmx128m", "-Xms128m", "-Xlog:pagesize:thp-%p.log", "-XX:+UseTransparentHugePages", "-XX:+UseCompressedOops", VerifyTHPEnabledForHeap.class.getName()); Is this the correct way to verify it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3289363658 PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3289408042 From duke at openjdk.org Sun Sep 14 12:09:06 2025 From: duke at openjdk.org (fabioromano1) Date: Sun, 14 Sep 2025 12:09:06 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v6] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: <0Yp8y7W5G8womTCDOPT8wUndSSGVrX89cdD9n0IKJtI=.4f592068-f194-4adb-9bb9-032f67d80b66@github.com> > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. > [Here is a proof for the formula.](https://github.com/user-attachments/files/22314648/frazioni_decimali.pdf) fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Extend log5Upper() for negative integers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/b3e985c2..7db21481 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 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 From duke at openjdk.org Sun Sep 14 12:14:54 2025 From: duke at openjdk.org (fabioromano1) Date: Sun, 14 Sep 2025 12:14:54 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v7] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: <5px1k01NCbGTdJPRvsjxdThl74OzRkZPOboxnSBirac=.1a70f4e7-c73d-463c-b8c7-5cbd8cf2e930@github.com> > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. > [Here is a proof for the formula.](https://github.com/user-attachments/files/22314648/frazioni_decimali.pdf) fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Comment refinement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/7db21481..4bbc4db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From duke at openjdk.org Sun Sep 14 16:29:06 2025 From: duke at openjdk.org (fabioromano1) Date: Sun, 14 Sep 2025 16:29:06 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v8] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Get the code much faster ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/4bbc4db3..4fbe2764 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=06-07 Stats: 70 lines in 1 file changed: 42 ins; 0 del; 28 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 From duke at openjdk.org Sun Sep 14 16:55:58 2025 From: duke at openjdk.org (fabioromano1) Date: Sun, 14 Sep 2025 16:55:58 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v9] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: <-14RbTDtLRGVK8Y2X368esxbZUGpVtdzhRCTyqhGW2M=.ab40b7f3-86ac-48ab-a520-b45b8261de6b@github.com> > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Optimizations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/4fbe2764..3d7e2faf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 From duke at openjdk.org Sun Sep 14 17:20:00 2025 From: duke at openjdk.org (fabioromano1) Date: Sun, 14 Sep 2025 17:20:00 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v10] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/3d7e2faf..8cb4066c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=08-09 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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 From duke at openjdk.org Sun Sep 14 21:10:13 2025 From: duke at openjdk.org (Johannes Graham) Date: Sun, 14 Sep 2025 21:10:13 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> Message-ID: On Mon, 8 Sep 2025 02:27:10 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'upstream/master' into appendPair_202508 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding > - Use DecimalDigits.appendPair for formatting in time classes > > This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. > > Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. > > Co-authored-by: Qwen-Coder > - Optimize year formatting in DateTimeHelper by reducing modulo operation > > Co-authored-by: Qwen-Coder > > Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. > - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. > > Co-authored-by: Qwen-Coder > - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. > > Co-authored-by: Qwen-Coder What is the performance like with a simpler implementation of DecimalDigits.appendPair? One that uses the DIGITS table and then simply appends each character. This would avoid the JavaLangAccess concern, but might still provide some of the benefit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3289899032 From duke at openjdk.org Mon Sep 15 02:22:46 2025 From: duke at openjdk.org (erifan) Date: Mon, 15 Sep 2025 02:22:46 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v12] In-Reply-To: References: Message-ID: > This patch optimizes the following patterns: > For integer types: > > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. > > For float and double types: > > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: > > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 > testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 > testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 > testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 > testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 > testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 > testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 > testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 > testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 > testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 > testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 > testCompareLTMaskNotLong ops/s 856502.26... erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: - Simplify JMH testing - Merge branch 'master' into JDK-8354242 - Update the code comment - Align indentation - Merge branch 'master' into JDK-8354242 - Address more comments ATT. - Merge branch 'master' into JDK-8354242 - Support negating unsigned comparison for BoolTest::mask Added a static method `negate_mask(mask btm)` into BoolTest class to negate both signed and unsigned comparison. - Addressed some review comments - Merge branch 'master' into JDK-8354242 - ... and 10 more: https://git.openjdk.org/jdk/compare/4d660b21...52bbd3cd ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24674/files - new: https://git.openjdk.org/jdk/pull/24674/files/04142a19..52bbd3cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=10-11 Stats: 129948 lines in 3408 files changed: 76187 ins; 35380 del; 18381 mod Patch: https://git.openjdk.org/jdk/pull/24674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674 PR: https://git.openjdk.org/jdk/pull/24674 From swen at openjdk.org Mon Sep 15 02:27:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 15 Sep 2025 02:27:18 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Sat, 23 Aug 2025 10:23:15 GMT, Shaojin Wen wrote: > localDateTimeToString @j3graham public static void appendPair(StringBuilder buf, int v) { int packed = DIGITS[v & 0x7f]; buf.append((char) (packed & 0xFF)) .append((char) (packed >> 8)); } I have tested this implementation and the performance is not good ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3290256444 From swen at openjdk.org Mon Sep 15 02:27:23 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 15 Sep 2025 02:27:23 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Wed, 27 Aug 2025 11:45:09 GMT, Mikhail Yankelevich wrote: >> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge remote-tracking branch 'upstream/master' into appendPair_202508 >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java >> - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding >> - Use DecimalDigits.appendPair for formatting in time classes >> >> This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. >> >> Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. >> >> Co-authored-by: Qwen-Coder >> - Optimize year formatting in DateTimeHelper by reducing modulo operation >> >> Co-authored-by: Qwen-Coder >> >> Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. >> - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. >> >> Co-authored-by: Qwen-Coder >> - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. >> >> Co-authored-by: Qwen-Coder > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 455: > >> 453: * If the value is between 0 and 9, it is formatted with a leading zero >> 454: * (e.g., 5 becomes "05"). If the value is outside the range 0-99, >> 455: * the behavior is unspecified. > > Just out of interest, why leave the behaviour as unspecified instead of validating and throwing an exception? Just simply trust the caller ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2347758316 From duke at openjdk.org Mon Sep 15 02:30:21 2025 From: duke at openjdk.org (erifan) Date: Mon, 15 Sep 2025 02:30:21 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v11] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 13:03:03 GMT, Emanuel Peter wrote: >> erifan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the code comment > > test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 1007: > >> 1005: testCompareMaskNotFloat(F_SPECIES, VectorOperators.NE, fa, fninf, (m) -> { return F_SPECIES.maskAll(true).xor(m); }); >> 1006: verifyResultsFloat(F_SPECIES, VectorOperators.NE, fa, fninf); >> 1007: } > > Do you have test cases for the cases other than `EQ` and `NE`? After all, we don't that someone accidentally messes with the logic you implemented later and we don't notice the bug ;) For `float` and `double`, only `EQ` and `NE` are supported. So the positive test only includes these two OPs. And we have one negative test for other unsupported OPs, see `testCompareMaskNotFloatNegative`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2347761055 From liach at openjdk.org Mon Sep 15 03:10:11 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 03:10:11 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> Message-ID: On Mon, 8 Sep 2025 02:27:10 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'upstream/master' into appendPair_202508 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding > - Use DecimalDigits.appendPair for formatting in time classes > > This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. > > Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. > > Co-authored-by: Qwen-Coder > - Optimize year formatting in DateTimeHelper by reducing modulo operation > > Co-authored-by: Qwen-Coder > > Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. > - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. > > Co-authored-by: Qwen-Coder > - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. > > Co-authored-by: Qwen-Coder If we have string templates in the future, do you think we can replace this with custom string template processors instead to accomplish the same performance (no redundant width checks)? test/jdk/jdk/internal/util/DecimalDigitsTest.java line 33: > 31: /* > 32: * @test > 33: * @bug 0000000 Suggestion: * @bug 8366224 ------------- PR Review: https://git.openjdk.org/jdk/pull/26911#pullrequestreview-3222746717 PR Review Comment: https://git.openjdk.org/jdk/pull/26911#discussion_r2347762729 From liach at openjdk.org Mon Sep 15 03:18:18 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 03:18:18 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> Message-ID: On Mon, 8 Sep 2025 02:27:10 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'upstream/master' into appendPair_202508 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java > - Add DecimalDigitsTest to verify appendPair method with LATIN1 and UTF16 encoding > - Use DecimalDigits.appendPair for formatting in time classes > > This change modifies the toString() methods in MonthDay, YearMonth, ZoneOffset, and ChronoLocalDateImpl to use DecimalDigits.appendPair for formatting two-digit numbers. This provides a more efficient and consistent way to format these values. > > Also added a comment in ChronoLocalDateImpl.toString() to explain why get() is used instead of getLong() for performance reasons, as the values are guaranteed to be within the int range for all chronologies. > > Co-authored-by: Qwen-Coder > - Optimize year formatting in DateTimeHelper by reducing modulo operation > > Co-authored-by: Qwen-Coder > > Refactored the year formatting logic to use subtraction instead of modulo for calculating the lower two digits, which can be slightly more efficient. Added a comment to clarify the safety of the input range for DecimalDigits.appendPair. > - Refactor DateTimeHelper to use DecimalDigits.appendPair for date/time formatting\n\nThis change updates DateTimeHelper.formatTo methods for LocalDate and LocalTime\nto use the new DecimalDigits.appendPair method for formatting month, day, hour,\nminute, and second components. This improves code clarity and leverages the\nnewly introduced efficient two-digit integer appending functionality. > > Co-authored-by: Qwen-Coder > - Introduce appendPair method for efficient two-digit integer appending\n\nThis change adds a new internal API to efficiently append two-digit integers\n(00-99) to a StringBuilder. It includes:\n- AbstractStringBuilder.appendPair(int i): The core implementation.\n- JavaLangAccess.appendPair(StringBuilder, int): For internal access.\n- System.JavaLangAccessImpl.appendPair(StringBuilder, int): Bridge to AbstractStringBuilder.\n- DecimalDigits.appendPair(StringBuilder, int): Public static utility method.\n\nImproved Javadoc comments for clarity and consistency across all new methods. > > Co-authored-by: Qwen-Coder This solution, if it is to be accepted, can only be a stopgap measure - I think the most likely feature to replace this hack would be String Templates. What abilities do you think that String Templates should support so that you can cover this use case (when we migrate the DateTimeFormatter to be String template instead of StringBuilder based)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3290328094 From duke at openjdk.org Mon Sep 15 05:43:11 2025 From: duke at openjdk.org (erifan) Date: Mon, 15 Sep 2025 05:43:11 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v13] In-Reply-To: References: Message-ID: > This patch optimizes the following patterns: > For integer types: > > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. > > For float and double types: > > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: > > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 > testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 > testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 > testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 > testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 > testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 > testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 > testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 > testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 > testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 > testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 > testCompareLTMaskNotLong ops/s 856502.26... erifan has updated the pull request incrementally with one additional commit since the last revision: Add an IR rule for vector mask cast operation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24674/files - new: https://git.openjdk.org/jdk/pull/24674/files/52bbd3cd..56bb34ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=11-12 Stats: 40 lines in 1 file changed: 40 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674 PR: https://git.openjdk.org/jdk/pull/24674 From duke at openjdk.org Mon Sep 15 05:43:14 2025 From: duke at openjdk.org (erifan) Date: Mon, 15 Sep 2025 05:43:14 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v11] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 13:04:48 GMT, Emanuel Peter wrote: >> erifan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update the code comment > > test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java line 911: > >> 909: testCompareMaskNotLong(L_SPECIES_FOR_CAST, VectorOperators.UGE, (m) -> { return m.cast(I_SPECIES_FOR_CAST).not(); }); >> 910: verifyResultsLong(L_SPECIES_FOR_CAST, VectorOperators.UGE); >> 911: } > > You have some cast in here, and in similar tests. > Can you add an IR rule to check if we do or do not have the expected casts? Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2347920402 From duke at openjdk.org Mon Sep 15 05:46:36 2025 From: duke at openjdk.org (erifan) Date: Mon, 15 Sep 2025 05:46:36 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v7] In-Reply-To: References: <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com> Message-ID: On Wed, 10 Sep 2025 07:43:20 GMT, Emanuel Peter wrote: >> Hi @eme64 @theRealAph @XiaohongGong @fg1417 @shqking , could you help take a look at this PR, thanks > > @erifan Sounds good. No rush, it takes as long as it takes. I'll soon be on vacation too and may not respond until mid of October. Hi @eme64 I have dealt with all of your suggestions except one that I think it has already been covered. Could you please have a look at this PR when you have a chance? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-3290572086 From ghan at openjdk.org Mon Sep 15 05:46:37 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 15 Sep 2025 05:46:37 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument Message-ID: trivial fix ------------- Commit messages: - Update Util.java Changes: https://git.openjdk.org/jdk/pull/27280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367619 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27280/head:pull/27280 PR: https://git.openjdk.org/jdk/pull/27280 From alanb at openjdk.org Mon Sep 15 05:55:28 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Sep 2025 05:55:28 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v3] In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 09:35:54 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. >> >> The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. >> >> tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > move the check to Shutdown.exit() Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27270#pullrequestreview-3223002502 From swen at openjdk.org Mon Sep 15 06:11:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 15 Sep 2025 06:11:18 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: > This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. > > Changes include: > > 1. New `appendPair` method for efficient two-digit integer formatting (00-99): > - Added `AbstractStringBuilder.appendPair(int i)` with core implementation > - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access > - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge > - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method > - Enhanced Javadoc documentation for all new methods > > 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: > - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` > - Replaced manual formatting logic with the new efficient two-digit appending > - Improved code clarity and consistency in date/time formatting > > These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/jdk/internal/util/DecimalDigitsTest.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26911/files - new: https://git.openjdk.org/jdk/pull/26911/files/a7ffb777..d489f144 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26911&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26911.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26911/head:pull/26911 PR: https://git.openjdk.org/jdk/pull/26911 From pminborg at openjdk.org Mon Sep 15 06:49:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 15 Sep 2025 06:49:15 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> On Mon, 15 Sep 2025 06:11:18 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/jdk/internal/util/DecimalDigitsTest.java > > Co-authored-by: Chen Liang We have, for long, established that changes like this should be discussed before putting forward any code. Yet, I am unable to find any discussion in the appropriate mailing list. Please send me the link to the mailing list discussion. I must have missed it for some reason. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3290708624 From duke at openjdk.org Mon Sep 15 07:14:15 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 15 Sep 2025 07:14:15 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v11] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/8cb4066c..256b5ac5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From tschatzl at openjdk.org Mon Sep 15 07:18:14 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 07:18:14 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * iwalulya review * documentation for a few PSS members * rename some member variables to contain _ct and _rt suffixes in remembered set verification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/1ced9f98..bf8cab33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=60 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=59-60 Stats: 25 lines in 3 files changed: 10 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From duke at openjdk.org Mon Sep 15 07:25:10 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 15 Sep 2025 07:25:10 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v12] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/256b5ac5..77974eb0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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 From duke at openjdk.org Mon Sep 15 07:39:00 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 15 Sep 2025 07:39:00 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v13] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: <8HZeA3EYJ7CqNxlQnUAxFCwU_Aqehf01H0YaOFQgptg=.910d8f19-b5b0-4f00-8404-9368bf6ac20e@github.com> > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/77974eb0..77dfc536 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=11-12 Stats: 15 lines in 1 file changed: 4 ins; 7 del; 4 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 From ghan at openjdk.org Mon Sep 15 07:41:23 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 15 Sep 2025 07:41:23 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string Message-ID: Please review this patch. **Description:** Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. **Test:** GHA ------------- Commit messages: - Change return type of utfLen to long to prevent overflow Changes: https://git.openjdk.org/jdk/pull/27285/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27285&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366421 Stats: 24 lines in 4 files changed: 5 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/27285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27285/head:pull/27285 PR: https://git.openjdk.org/jdk/pull/27285 From swen at openjdk.org Mon Sep 15 08:28:28 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 15 Sep 2025 08:28:28 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> Message-ID: On Mon, 15 Sep 2025 06:45:25 GMT, Per Minborg wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test/jdk/jdk/internal/util/DecimalDigitsTest.java >> >> Co-authored-by: Chen Liang > > We have, for long, established that changes like this should be discussed before putting forward any code. Yet, I am unable to find any discussion in the appropriate mailing list. Please send me the link to the mailing list discussion. I must have missed it for some reason. @minborg The process went like this: On August 23rd, I posted an email to the core-libs-dev mailing list titled "Introduce and utilize DecimalDigits.appendPair for efficient two-digit formatting." The message included a link to the pull request (PR) https://github.com/openjdk/jdk/pull/26911. At the time, the PR was in draft status. On August 26th, @jodastephen commented on the PR. He's an expert in java.time, and based on his comments, I created an issue and changed the PR status to RFR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3291005980 From fandreuzzi at openjdk.org Mon Sep 15 08:29:24 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Mon, 15 Sep 2025 08:29:24 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:37:58 GMT, Guanqiang Han wrote: > trivial fix Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27280#pullrequestreview-3223443676 From pminborg at openjdk.org Mon Sep 15 09:05:24 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 15 Sep 2025 09:05:24 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> Message-ID: On Mon, 15 Sep 2025 06:45:25 GMT, Per Minborg wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test/jdk/jdk/internal/util/DecimalDigitsTest.java >> >> Co-authored-by: Chen Liang > > We have, for long, established that changes like this should be discussed before putting forward any code. Yet, I am unable to find any discussion in the appropriate mailing list. Please send me the link to the mailing list discussion. I must have missed it for some reason. > @minborg > > The process went like this: > > On August 23rd, I posted an email to the core-libs-dev mailing list titled "Introduce and utilize DecimalDigits.appendPair for efficient two-digit formatting." The message included a link to the pull request (PR) #26911. At the time, the PR was in draft status. > > On August 26th, @jodastephen commented on the PR. > > He's an expert in java.time, and based on his comments, I created an issue and changed the PR status to RFR. This mail appears to merely point out that there is a PR with code. I am unable to locate any discussion *prior* to any code being presented. E.g., whether we should do this or not. What are the pros and cons, etc. What did I miss? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3291135881 From jbhateja at openjdk.org Mon Sep 15 09:38:14 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 15 Sep 2025 09:38:14 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v13] In-Reply-To: References: Message-ID: <4D63cqV0LkPYrSMSkfachZzoH_qpH9vhAbo57RRe1Js=.7a21d73b-7963-4e15-b013-8295b274d5d0@github.com> On Mon, 15 Sep 2025 05:43:11 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request incrementally with one additional commit since the last revision: > > Add an IR rule for vector mask cast operation Your benchmark and code changes look good to me. Thanks for addressing my comments. ------------- Marked as reviewed by jbhateja (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-3223705838 From duke at openjdk.org Mon Sep 15 09:49:19 2025 From: duke at openjdk.org (erifan) Date: Mon, 15 Sep 2025 09:49:19 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v13] In-Reply-To: <4D63cqV0LkPYrSMSkfachZzoH_qpH9vhAbo57RRe1Js=.7a21d73b-7963-4e15-b013-8295b274d5d0@github.com> References: <4D63cqV0LkPYrSMSkfachZzoH_qpH9vhAbo57RRe1Js=.7a21d73b-7963-4e15-b013-8295b274d5d0@github.com> Message-ID: <0SEFllVEITC_xA1OeWHnPC0S9-nbnicZOCKlAcbwH1M=.ecc56fb6-45fd-44c9-a9ca-4a5f5a391a34@github.com> On Mon, 15 Sep 2025 09:33:47 GMT, Jatin Bhateja wrote: >> erifan has updated the pull request incrementally with one additional commit since the last revision: >> >> Add an IR rule for vector mask cast operation > > Your benchmark and code changes look good to me. Thanks for addressing my comments. Thanks @jatin-bhateja . And the updated benchmarks test results are as follow, no much changes. On Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: Benchmark COMPARISON_OP Unit Before Score Error After Score Error Uplift testCompareMaskNotDouble EQ ops/s 908008.7644 827.699314 1175289.515 240.548861 1.294359 testCompareMaskNotDouble NE ops/s 872199.2489 131.090115 1175667.777 129.741515 1.347934 testCompareMaskNotDouble LT ops/s 880166.7559 1570.41653 882160.6889 4723.507639 1.002265 testCompareMaskNotDouble LE ops/s 878115.3293 2919.637497 879033.7895 5404.617017 1.001045 testCompareMaskNotDouble GT ops/s 877068.5325 9595.275981 865832.864 5054.26002 0.987189 testCompareMaskNotDouble GE ops/s 895695.0228 3276.687933 871153.7117 7714.572967 0.9726 testCompareMaskNotFloat EQ ops/s 1811841.295 278.140948 2350971.83 606.667654 1.297559 testCompareMaskNotFloat NE ops/s 1727124.634 1755.717051 2351789.019 269.531198 1.361678 testCompareMaskNotFloat LT ops/s 1735243.319 4912.343726 1726257.01 823.746765 0.994821 testCompareMaskNotFloat LE ops/s 1726151.367 1071.383328 1727029.339 960.336314 1.000508 testCompareMaskNotFloat GT ops/s 1729704.897 1646.026351 1726069.02 440.981281 0.997897 testCompareMaskNotFloat GE ops/s 1726515.227 2171.61643 1728365.682 1404.298156 1.001071 testCompareMaskNotByte EQ ops/s 8480574.694 1254.415788 10200329.86 8560.199493 1.202787 testCompareMaskNotByte NE ops/s 8480141.263 1437.762594 10207424.91 3664.106923 1.203685 testCompareMaskNotByte LT ops/s 8471471.384 7699.585554 10203300.19 4675.047416 1.20443 testCompareMaskNotByte LE ops/s 8476165.519 6045.944392 10204956.23 2174.866199 1.203959 testCompareMaskNotByte GT ops/s 8479397.377 1290.560961 10207032.3 5414.789178 1.203745 testCompareMaskNotByte GE ops/s 8479979.908 1094.823175 10203115.77 2909.433184 1.2032 testCompareMaskNotByte ULT ops/s 8480915.515 1420.30856 10213140.54 19628.56888 1.204249 testCompareMaskNotByte ULE ops/s 8481768.961 1806.086454 10191601.05 9537.089409 1.201589 testCompareMaskNotByte UGT ops/s 8477948.807 3652.437106 10208439.79 8335.226416 1.204116 testCompareMaskNotByte UGE ops/s 8477320.065 2191.753237 10198589.9 5748.761942 1.203044 testCompareMaskNotInt EQ ops/s 1906386.393 208.045573 2346741.129 383.461819 1.230989 testCompareMaskNotInt NE ops/s 1674206.146 169.967081 2346609.602 652.964692 1.401625 testCompareMaskNotInt LT ops/s 1684755.085 4939.806653 2345939.728 738.842445 1.392451 testCompareMaskNotInt LE ops/s 1659985.83 2408.542766 2346929.8 192.550397 1.413825 testCompareMaskNotInt GT ops/s 1674460.437 447.120589 2347037.155 342.433085 1.401667 testCompareMaskNotInt GE ops/s 1658699.073 884.268891 2347411.827 281.885914 1.415212 testCompareMaskNotInt ULT ops/s 1677043.66 6215.834359 2347155.384 425.141786 1.399579 testCompareMaskNotInt ULE ops/s 1667049.76 9521.094204 2346815.213 316.03901 1.407765 testCompareMaskNotInt UGT ops/s 1661045.828 3669.548525 2346711.365 2808.608132 1.412791 testCompareMaskNotInt UGE ops/s 1663715.691 4570.73053 2347096.847 191.804359 1.410755 testCompareMaskNotLong EQ ops/s 885668.5947 203.053456 1174274.006 113.51354 1.325861 testCompareMaskNotLong NE ops/s 837449.9353 198.611966 1174330.269 106.514374 1.402269 testCompareMaskNotLong LT ops/s 846790.2128 7005.585657 1174290.879 93.56413 1.386755 testCompareMaskNotLong LE ops/s 851253.2346 7624.045467 1174162.355 179.854316 1.379333 testCompareMaskNotLong GT ops/s 837715.7563 4272.558281 1173797.819 289.311518 1.401188 testCompareMaskNotLong GE ops/s 883137.593 14804.63746 1174216.909 86.404559 1.329596 testCompareMaskNotLong ULT ops/s 872478.9017 4955.722542 1174341.995 124.656933 1.345983 testCompareMaskNotLong ULE ops/s 866570.738 12541.58528 1174185.197 594.850706 1.354979 testCompareMaskNotLong UGT ops/s 866389.0927 3971.492766 1174210.803 153.960084 1.355292 testCompareMaskNotLong UGE ops/s 848339.3876 4555.514721 1174060.638 240.326562 1.383951 testCompareMaskNotShort EQ ops/s 3336170.783 2286.717236 4684904.156 2134.72575 1.404275 testCompareMaskNotShort NE ops/s 3334775.472 717.588615 4690264.12 3017.756867 1.40647 testCompareMaskNotShort LT ops/s 3334619.058 1138.901707 4685883.864 3808.321694 1.405223 testCompareMaskNotShort LE ops/s 3335538.353 538.676789 4688238.934 1029.406266 1.405541 testCompareMaskNotShort GT ops/s 3301425.217 694.060525 4689167.049 2845.363801 1.420346 testCompareMaskNotShort GE ops/s 3301580.972 317.042851 4688970.211 1292.83929 1.420219 testCompareMaskNotShort ULT ops/s 3336318.051 892.515034 4687549.384 1403.281648 1.405006 testCompareMaskNotShort ULE ops/s 3335188.292 972.230191 4684723.63 3937.599084 1.404635 testCompareMaskNotShort UGT ops/s 3334490.656 930.409628 4688058.378 1166.776081 1.405929 testCompareMaskNotShort UGE ops/s 3333050.033 3146.019596 4689197.9 456.439188 1.406878 With option `-XX:UseSVE=0`: Benchmark COMPARISON_OP Unit Before Score Error After Score Error Uplift testCompareMaskNotDouble EQ ops/s 788505.9464 579.254839 769969.5798 138.792325 0.976491 testCompareMaskNotDouble NE ops/s 655499.7935 471.970429 915086.3257 183.495964 1.396013 testCompareMaskNotDouble LT ops/s 788418.7889 574.263314 789271.7448 51.838991 1.001081 testCompareMaskNotDouble LE ops/s 789144.8431 45.334181 789326.1963 84.148011 1.000229 testCompareMaskNotDouble GT ops/s 788690.8485 662.950083 789246.9812 99.060588 1.000705 testCompareMaskNotDouble GE ops/s 789421.2387 94.012868 789166.4717 111.772533 0.999677 testCompareMaskNotFloat EQ ops/s 1816132.864 1298.2187 1816461.601 311.706275 1.000181 testCompareMaskNotFloat NE ops/s 1550767.697 1142.987761 2301429.148 159.71525 1.484057 testCompareMaskNotFloat LT ops/s 1815531.685 1370.868745 1817187.121 761.68401 1.000911 testCompareMaskNotFloat LE ops/s 1817937.722 484.638134 1817703.209 625.275639 0.999871 testCompareMaskNotFloat GT ops/s 1818618.89 724.324392 1817977.851 481.152488 0.999647 testCompareMaskNotFloat GE ops/s 1815118.411 1327.945736 1817476.414 510.712942 1.001299 testCompareMaskNotByte EQ ops/s 6489599.571 5127.815254 6535895.286 17029.15534 1.007133 testCompareMaskNotByte NE ops/s 9089974.523 4069.346579 15945662.17 22867.48282 1.754203 testCompareMaskNotByte LT ops/s 6499040.898 1250.085336 15939338.57 17451.05939 2.452567 testCompareMaskNotByte LE ops/s 6493612.339 4928.466061 15926355.01 27249.57103 2.452618 testCompareMaskNotByte GT ops/s 6494486.565 5229.4598 15957497.14 6893.237334 2.457083 testCompareMaskNotByte GE ops/s 6499295.661 1030.044749 15903755.01 46454.70992 2.446996 testCompareMaskNotByte ULT ops/s 6494212.684 5194.712704 15944816.71 3467.818892 2.455234 testCompareMaskNotByte ULE ops/s 6493882.576 5092.839387 15936419.25 22755.34523 2.454066 testCompareMaskNotByte UGT ops/s 6493479.899 4678.096391 15958133.18 3483.353667 2.457562 testCompareMaskNotByte UGE ops/s 6500338.419 709.344957 15968155.27 14020.47085 2.456511 testCompareMaskNotInt EQ ops/s 1830787.273 237.597163 1878452.588 142.728192 1.026035 testCompareMaskNotInt NE ops/s 1615081.395 1219.871461 2360913.712 199.556675 1.461792 testCompareMaskNotInt LT ops/s 1827819.867 1360.728526 2360561.422 248.025925 1.291462 testCompareMaskNotInt LE ops/s 1830975.648 416.987529 2360703.924 194.958346 1.289314 testCompareMaskNotInt GT ops/s 1830633.964 301.849017 2360552.203 224.908655 1.289472 testCompareMaskNotInt GE ops/s 1829476.495 1348.361278 2360673.736 137.538696 1.290354 testCompareMaskNotInt ULT ops/s 1829137.773 1285.55232 2360615.95 162.876291 1.290562 testCompareMaskNotInt ULE ops/s 1828107.468 1360.867847 2360790.337 297.267481 1.291384 testCompareMaskNotInt UGT ops/s 1829659.222 1459.098806 2361025.107 266.158075 1.290417 testCompareMaskNotInt UGE ops/s 1829548.187 1427.266787 2360941.943 242.380469 1.29045 testCompareMaskNotLong EQ ops/s 810439.9121 82.577412 802287.4993 73.462086 0.98994 testCompareMaskNotLong NE ops/s 681643.6089 485.657471 932324.6973 158.28799 1.367759 testCompareMaskNotLong LT ops/s 809850.546 680.71673 931404.3219 685.591444 1.150094 testCompareMaskNotLong LE ops/s 810584.5191 115.234753 932234.2412 105.451172 1.150076 testCompareMaskNotLong GT ops/s 810593.5376 117.947863 931879.1829 553.397713 1.149625 testCompareMaskNotLong GE ops/s 810435.8405 81.88737 931833.0348 177.765694 1.149792 testCompareMaskNotLong ULT ops/s 810429.8459 90.005329 932127.5278 74.443387 1.150164 testCompareMaskNotLong ULE ops/s 809740.842 411.655134 932231.6607 76.044104 1.151271 testCompareMaskNotLong UGT ops/s 810493.4369 52.024062 932239.1709 143.915229 1.150211 testCompareMaskNotLong UGE ops/s 810442.0661 64.064396 932361.567 119.570287 1.150435 testCompareMaskNotShort EQ ops/s 4786426.182 299.050738 4694123.013 482.608634 0.980715 testCompareMaskNotShort NE ops/s 3808932.807 2993.590606 5672255.469 6262.526335 1.489198 testCompareMaskNotShort LT ops/s 4782535.485 3699.104322 5668474.071 11101.86452 1.185244 testCompareMaskNotShort LE ops/s 4782896.891 3338.57484 5669188.434 6309.723399 1.185304 testCompareMaskNotShort GT ops/s 4778532.318 3571.547653 5680482.703 10427.66734 1.18875 testCompareMaskNotShort GE ops/s 4786150.851 794.769881 5664644.919 6542.434538 1.183549 testCompareMaskNotShort ULT ops/s 4783623.78 3582.962421 5668267.123 17841.44773 1.184931 testCompareMaskNotShort ULE ops/s 4782752.125 3610.296618 5666231.302 6964.505363 1.184721 testCompareMaskNotShort UGT ops/s 4782469.332 2913.37576 5655837.96 6494.608864 1.182618 testCompareMaskNotShort UGE ops/s 4782606.35 3491.774067 5667295.182 14176.96543 1.18498 On AMD EPYC 9124 16-Core Processor: With option `-XX:UseAVX=3`: Benchmark COMPARISON_OP Unit Before Score Error After Score Error Uplift testCompareMaskNotDouble EQ ops/s 2166357.886 27577.51358 2920183.192 38491.49083 1.347968 testCompareMaskNotDouble NE ops/s 2177325.341 32771.27023 2965747.932 39271.62615 1.362106 testCompareMaskNotDouble LT ops/s 2123834.711 22890.39919 2197099.169 29107.41329 1.034496 testCompareMaskNotDouble LE ops/s 2172931.681 32912.05647 2121686.057 34927.37781 0.976416 testCompareMaskNotDouble GT ops/s 2164924.662 30925.91899 2124062.892 37135.0458 0.981125 testCompareMaskNotDouble GE ops/s 2150619.038 35515.09022 2192636.533 38672.85716 1.019537 testCompareMaskNotFloat EQ ops/s 4518378.764 74733.72389 6724589.409 50424.63568 1.488274 testCompareMaskNotFloat NE ops/s 4522823.224 78138.66727 6907565.257 203953.3299 1.527268 testCompareMaskNotFloat LT ops/s 4587473.545 62621.25938 4431658.918 52760.23989 0.966034 testCompareMaskNotFloat LE ops/s 4472078.986 79338.23304 4472390.043 66247.285 1.000069 testCompareMaskNotFloat GT ops/s 4451744.39 220787.9755 4440866.486 58674.19154 0.997556 testCompareMaskNotFloat GE ops/s 4459601.349 57873.05167 4481398.426 76819.69285 1.004887 testCompareMaskNotByte EQ ops/s 19415317.92 356367.4937 20649319.86 240515.9459 1.063558 testCompareMaskNotByte NE ops/s 19401162.58 362571.8103 21010358.2 71221.35255 1.082943 testCompareMaskNotByte LT ops/s 19175612.37 273080.6175 20235838.72 396190.6101 1.05529 testCompareMaskNotByte LE ops/s 19036831.33 121135.0491 20674528.84 248839.9471 1.086027 testCompareMaskNotByte GT ops/s 19008302.3 124633.9182 20671390.89 271644.5576 1.087492 testCompareMaskNotByte GE ops/s 19590753.42 429156.452 20491615.07 332912.82 1.045984 testCompareMaskNotByte ULT ops/s 19431604.06 421396.5487 20575805.9 248466.2368 1.058883 testCompareMaskNotByte ULE ops/s 19060425.47 98309.75469 20774930.43 206596.0422 1.089951 testCompareMaskNotByte UGT ops/s 19266788.04 362893.3051 20861521.87 106977.3707 1.082771 testCompareMaskNotByte UGE ops/s 19127964.33 447774.3747 20791221.56 254458.0132 1.086954 testCompareMaskNotInt EQ ops/s 4473402.48 84902.77154 7191777.028 94315.13878 1.607674 testCompareMaskNotInt NE ops/s 4583165.363 73491.79073 7249884.988 80028.31191 1.581851 testCompareMaskNotInt LT ops/s 4618634.192 81869.82512 7242567.732 71211.3697 1.568118 testCompareMaskNotInt LE ops/s 4650524.195 72302.56692 7154948.491 83057.90635 1.538525 testCompareMaskNotInt GT ops/s 4534752.486 94449.20198 7004428.251 38365.18576 1.54461 testCompareMaskNotInt GE ops/s 4540777.389 86331.11847 7129527.341 74343.06996 1.570111 testCompareMaskNotInt ULT ops/s 4528175.644 114213.6504 7220013.98 82850.22587 1.594464 testCompareMaskNotInt ULE ops/s 4619335.448 74203.98889 7118543.128 54457.43284 1.541031 testCompareMaskNotInt UGT ops/s 4572521.254 122912.75 7154797.741 98858.3477 1.564737 testCompareMaskNotInt UGE ops/s 4579627.842 80558.04554 7179020.593 99239.23499 1.567599 testCompareMaskNotLong EQ ops/s 2103965.347 17059.28178 2997338.009 32388.42725 1.424613 testCompareMaskNotLong NE ops/s 2174434.633 36011.24708 2984460.593 29074.42994 1.372522 testCompareMaskNotLong LT ops/s 2110937.378 56642.0052 3020690.893 31167.62537 1.430971 testCompareMaskNotLong LE ops/s 2153414.166 31280.20562 2971696.162 31176.24605 1.379992 testCompareMaskNotLong GT ops/s 2166028.207 49432.18925 3008018.282 26534.78551 1.388725 testCompareMaskNotLong GE ops/s 2178206.136 35757.6799 2933186.687 19824.26727 1.346606 testCompareMaskNotLong ULT ops/s 2104344.728 31405.7728 2964354.007 26871.18289 1.408682 testCompareMaskNotLong ULE ops/s 2210232.578 21993.95777 3032635.261 25545.43656 1.372088 testCompareMaskNotLong UGT ops/s 2167177.931 44896.90807 2996245.236 34153.68941 1.382556 testCompareMaskNotLong UGE ops/s 2117175.328 26131.1893 2977492.164 23227.65519 1.406351 testCompareMaskNotShort EQ ops/s 8131234.179 185997.1777 12414378.38 122648.1579 1.526752 testCompareMaskNotShort NE ops/s 8506016.656 236481.383 12720442.64 322747.8776 1.495464 testCompareMaskNotShort LT ops/s 8487868.819 244943.6097 12150479.62 244300.5456 1.431511 testCompareMaskNotShort LE ops/s 8549184.557 286833.466 12358019.06 136683.2112 1.44552 testCompareMaskNotShort GT ops/s 8375447.45 221237.073 12602058.97 385690.3318 1.504643 testCompareMaskNotShort GE ops/s 8123474.548 127727.1461 12799747.64 197940.1001 1.575649 testCompareMaskNotShort ULT ops/s 8491650.422 313124.2425 12751186.59 255845.1653 1.501614 testCompareMaskNotShort ULE ops/s 8363009.676 203670.1995 12675908.7 279496.9925 1.515711 testCompareMaskNotShort UGT ops/s 8332268.933 279787.2503 12279451.4 436971.6582 1.473722 testCompareMaskNotShort UGE ops/s 8931588.505 203962.9257 12324437.67 330723.3066 1.37987 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-3291304777 From jkern at openjdk.org Mon Sep 15 11:21:49 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 15 Sep 2025 11:21:49 GMT Subject: RFR: 8360401: [AIX] java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java fails since JDK-8210549 Message-ID: The new tests java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#fork java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#posix_spawn fail on AIX. The tests were added with [JDK-8210549](https://bugs.openjdk.org/browse/JDK-8210549) . Error output is java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#fork Opened and leaked ./testfile_FDLeaker.txt (4) ----------System.err:(13/647)---------- *** Parent leaked file descriptor 9 *** *** Parent leaked file descriptor 10 *** java.lang.RuntimeException: Failed at FDLeakTest.main(FDLeakTest.java:69) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) java/lang/ProcessBuilder/FDLeakTest/FDLeakTest.java#posix_spawn ----------System.out:(1/46)---------- Opened and leaked ./testfile_FDLeaker.txt (4) ----------System.err:(13/647)---------- *** Parent leaked file descriptor 9 *** *** Parent leaked file descriptor 10 *** java.lang.RuntimeException: Failed at FDLeakTest.main(FDLeakTest.java:69) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) ------------- Commit messages: - JDK-8360401 Changes: https://git.openjdk.org/jdk/pull/27291/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27291&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360401 Stats: 35 lines in 1 file changed: 22 ins; 8 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27291.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27291/head:pull/27291 PR: https://git.openjdk.org/jdk/pull/27291 From dfuchs at openjdk.org Mon Sep 15 11:38:24 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 15 Sep 2025 11:38:24 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v3] In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 09:35:54 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. >> >> The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. >> >> tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > move the check to Shutdown.exit() This looks reasonable to me but would be good to have @RogerRiggs review. ------------- PR Review: https://git.openjdk.org/jdk/pull/27270#pullrequestreview-3224184744 From dl at openjdk.org Mon Sep 15 12:01:24 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Sep 2025 12:01:24 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v8] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:29:53 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> revive topLevelExec, adjust occrdingly; small teaks and copy-edits > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 575: > >> 573: * or non-emptiness; all of which usually cause more activations >> 574: * than necessary (see below). (Method signalWork is also used as >> 575: * failsafe in case of Thread failures in deregisterWorker.) > > I think it is worth elaborating what this failsafe enables (i.e. how does it failsafe these failures) added: , to * activate or create a new worker to replace them). > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 598: > >> 596: * needs unparking upon signal. >> 597: * >> 598: * When tasks are constructed as (recursive) dags, top-level > > Suggestion: > > * When tasks are constructed as (recursive) DAGs, top-level Done > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 612: > >> 610: * stalls when tasks cannot be taken because other workers have >> 611: * not finished poll operations, which is detected by reading >> 612: * ahead in queue arrays. In both caes, workers restart scans in a > > Suggestion: > > * ahead in queue arrays. In both cases, workers restart scans in a thanks > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1224: > >> 1222: if ((this.owner = owner) == null) { >> 1223: phase = id | IDLE; >> 1224: array = new ForkJoinTask[INITIAL_QUEUE_CAPACITY]; > > Might be better to assign the array *before* assigning the phase as the latter is a volatile write? thanks; done. > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1951: > >> 1949: final void runWorker(WorkQueue w) { >> 1950: if (w != null) { >> 1951: int phase = w.phase; > > Given that this is a volatile read, and presuming that the timing of this read is important, perhaps add a comment on this line? No longer apples after reworking code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348750133 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348751688 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348752724 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348755855 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348760550 From dl at openjdk.org Mon Sep 15 12:01:30 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Sep 2025 12:01:30 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 11:34:19 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid underutilization on resize > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1290: > >> 1288: if (room == 0) { // resize >> 1289: growArray(a, cap, s); >> 1290: a = null; > > Suggestion: > > a = null; // Indicate resize to trigger signalling (No longer applies) > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1299: > >> 1297: if (pool != null && >> 1298: (a == null || // always signal on resize >> 1299: U.getReferenceAcquire(a, slotOffset(m & (s - 1))) == null)) > > @DougLea Interesting. Is the reason that it is cheaper to check `a` for null here that it elides a nullcheck in the getReferenceAcquire? (even if it adds the cost of nulling out `a` after growArray()) (No longer applies) > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2003: > >> 2001: continue rescan; >> 2002: if (b == (b = q.base) && a[bk] == null) { >> 2003: if (a[nk] == null && a[(b + 2) & m] == null) { > > @DougLea Seems worth it to add a comment around why we're looking at b + 2 here. sorta done (but with implicit ref to leading docs) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348768921 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348765617 PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348767307 From dl at openjdk.org Mon Sep 15 12:09:17 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Sep 2025 12:09:17 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 11:41:33 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid underutilization on resize > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2072: > >> 2070: p = awaitWork(w, p); // block, drop, or exit >> 2071: } >> 2072: } > > @DougLea if `w != null` is always expected to be `true`, it might make sense to throw some form of exception in case it actually is. Possibly an assertion? Added some comments. I settled on the convention (mentioned in docs) of always exiting on any null for the sake of clean termination. Even when nulls are currently impossible, foe the sake of future changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348786367 From dl at openjdk.org Mon Sep 15 12:15:05 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Sep 2025 12:15:05 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v8] In-Reply-To: References: Message-ID: <8FZgHXsK-7b2doKJbZICIwxggQ3JQgl0yPbFZCaZcx8=.303cf88a-9314-4143-9bda-d965e21e139d@github.com> On Thu, 11 Sep 2025 12:31:20 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> revive topLevelExec, adjust occrdingly; small teaks and copy-edits > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 605: > >> 603: * empty or contended, while also minimizing interference by >> 604: * postponing bookeeping to ends of runs. This may reduce >> 605: * fairness, which is partially counteracted by the following. > > This sentence ends in a weird manner for me. Is the intention that the dot should be a colon? Or is there missing text? I removed the uninformative "which is partially counteracted by the following" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348796569 From dl at openjdk.org Mon Sep 15 12:25:43 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Sep 2025 12:25:43 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v9] In-Reply-To: References: Message-ID: <9zxP30RM8-vptHjfml8VDmEN04s2j3nAn9WYmJZ55zM=.288e35d1-3247-4f38-bd7e-37053f542160@github.com> > This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Revert Exchanger for separate PR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26479/files - new: https://git.openjdk.org/jdk/pull/26479/files/31d2f486..b6b1356e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26479&range=07-08 Stats: 50 lines in 1 file changed: 13 ins; 3 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/26479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26479/head:pull/26479 PR: https://git.openjdk.org/jdk/pull/26479 From dl at openjdk.org Mon Sep 15 12:29:20 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Sep 2025 12:29:20 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v8] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:32:29 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> revive topLevelExec, adjust occrdingly; small teaks and copy-edits > > src/java.base/share/classes/java/util/concurrent/Exchanger.java line 276: > >> 274: static final class Node { >> 275: long seed; // Random seed >> 276: int index; // Arena index > > Just adding it here as a reminder (to myself if nothing else) that the changes to Exchanger.java should be in a separate PR for easier handling. (No longer applicable -- moved to different PR) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348829657 From dl at openjdk.org Mon Sep 15 12:29:22 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Sep 2025 12:29:22 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v5] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 11:27:10 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid underutilization on resize > > src/java.base/share/classes/java/util/concurrent/Exchanger.java line 380: > >> 378: (!ForkJoinWorkerThread.hasKnownQueuedWork()))) { >> 379: for (int j = SPINS; p.match == null && j > 0; --j) >> 380: Thread.onSpinWait(); > > It might not be worth it, but I wonder if something like this would make a positive impact: > > Suggestion: > > if (!(tryCancel = (deadline != 0L && > (ns = deadline - System.nanoTime()) <= 0L) || > Thread.currentThread().isInterrupted())) > && ncpu > 1 && > (i != 0 || /* check for busy VTs */ (!ForkJoinWorkerThread.hasKnownQueuedWork()))) { > for (int j = SPINS; p.match == null && j > 0; --j) > Thread.onSpinWait(); (No longer applicable -- moved to different PR) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348828552 From dl at openjdk.org Mon Sep 15 12:29:29 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Sep 2025 12:29:29 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v4] In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 11:30:01 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8360046 >> - Undo inadvertent acquire change >> - Add adapt(callable) case to test >> - Whitespace >> - Merge branch 'openjdk:master' into JDK-8360046 >> - Avoid unnecessary use of InterruptibleTask; misc cleanup >> - revert runWorker; tweak external probes >> - reduce contention >> - Merge branch 'openjdk:master' into JDK-8360046 >> - For testing >> - ... and 1 more: https://git.openjdk.org/jdk/compare/3be13288...c16c1282 > > src/java.base/share/classes/java/util/concurrent/Exchanger.java line 408: > >> 406: else if ((b & MMASK) != 0) { >> 407: misses = 0; // try to shrink >> 408: BOUND.compareAndSet(this, b, b - 1 + SEQ); > > Is the reasoning here that `deadline` cannot be == 0L, or that it doesn't matter anymore if it is? (No longer applicable -- moved to different PR) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348829095 From rriggs at openjdk.org Mon Sep 15 13:39:31 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Sep 2025 13:39:31 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v3] In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 09:35:54 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. >> >> The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. >> >> tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > move the check to Shutdown.exit() Looks good to me. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27270#pullrequestreview-3224659923 From weijun at openjdk.org Mon Sep 15 13:55:48 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Sep 2025 13:55:48 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Mon, 15 Sep 2025 06:11:18 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/jdk/internal/util/DecimalDigitsTest.java > > Co-authored-by: Chen Liang I'd rather see a real public API even if it looks like `StringBuilder::appendInteger(boolean alwaysSign, boolean packWithZero, int minWidth, int number)`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3292294887 From rriggs at openjdk.org Mon Sep 15 13:57:48 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Sep 2025 13:57:48 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:37:58 GMT, Guanqiang Han wrote: > trivial fix Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27280#pullrequestreview-3224763568 From duke at openjdk.org Mon Sep 15 14:14:38 2025 From: duke at openjdk.org (duke) Date: Mon, 15 Sep 2025 14:14:38 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: <63Ek-7QGr9ntN0woMkqg4TFrqb7bMjsrlGeVsN94l-E=.eafca4c8-1a20-4e3b-a62e-1f30198329f7@github.com> On Mon, 15 Sep 2025 05:37:58 GMT, Guanqiang Han wrote: > trivial fix @hgqxjj Your change (at version d88eedfc0605dea8eb759527c4d59d2515b099a7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27280#issuecomment-3292377027 From ghan at openjdk.org Mon Sep 15 14:17:54 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 15 Sep 2025 14:17:54 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 13:54:12 GMT, Roger Riggs wrote: >> trivial fix > > Looks good. @RogerRiggs @fandreuz Thank you for the review. I have integrated the changes , could you please kindly sponsor it? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27280#issuecomment-3292393381 From liach at openjdk.org Mon Sep 15 14:24:17 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 14:24:17 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:37:58 GMT, Guanqiang Han wrote: > trivial fix Marked as reviewed by liach (Reviewer). Looks like a typo I made. Interesting that the unit test passed because this method threw `IllegalFormatConversionException` which is also a subtype of `IllegalArgumentException` ? ------------- PR Review: https://git.openjdk.org/jdk/pull/27280#pullrequestreview-3224879479 PR Comment: https://git.openjdk.org/jdk/pull/27280#issuecomment-3292432759 From ghan at openjdk.org Mon Sep 15 14:24:18 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 15 Sep 2025 14:24:18 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 14:18:08 GMT, Chen Liang wrote: >> trivial fix > > Marked as reviewed by liach (Reviewer). @liach Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27280#issuecomment-3292425796 From coleenp at openjdk.org Mon Sep 15 14:25:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 14:25:29 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. This looks great. You said vmtarget but you meant vmholder, which is the right name for this internal field since it points to the mirror (instance of java.lang.Class). ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3224893210 From phubner at openjdk.org Mon Sep 15 14:25:30 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Mon, 15 Sep 2025 14:25:30 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: <3NcFIVzB54ClBeKBOMpzHFt9gHz-VY5tZGflXHpAXVQ=.f69ec18a-1732-404d-9f0a-c34af33698f1@github.com> On Mon, 15 Sep 2025 14:19:39 GMT, Coleen Phillimore wrote: > This looks great. You said vmtarget but you meant vmholder, which is the right name for this internal field since it points to the mirror (instance of java.lang.Class). Apologies, I've updated the PR description accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292440414 From liach at openjdk.org Mon Sep 15 14:31:25 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 14:31:25 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: <2FOqadscYG1kBv_BojGeGg5HxPM_JKJN5fy2rlFplpQ=.f0506803-1aad-4656-8e7d-183c6912da24@github.com> On Mon, 15 Sep 2025 05:37:58 GMT, Guanqiang Han wrote: > trivial fix Since there is a behavioral change, please let me run CI tests before sponsoring. Also note point 7 in https://openjdk.org/guide/#life-of-a-pr, that you should leave sufficient time for reviewers before typing `/integrate`. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27280#issuecomment-3292468332 From ghan at openjdk.org Mon Sep 15 14:31:26 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 15 Sep 2025 14:31:26 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: <2FOqadscYG1kBv_BojGeGg5HxPM_JKJN5fy2rlFplpQ=.f0506803-1aad-4656-8e7d-183c6912da24@github.com> References: <2FOqadscYG1kBv_BojGeGg5HxPM_JKJN5fy2rlFplpQ=.f0506803-1aad-4656-8e7d-183c6912da24@github.com> Message-ID: On Mon, 15 Sep 2025 14:27:49 GMT, Chen Liang wrote: >> trivial fix > > Since there is a behavioral change, please let me run CI tests before sponsoring. Also note point 7 in https://openjdk.org/guide/#life-of-a-pr, that you should leave sufficient time for reviewers before typing `/integrate`. Thanks! @liach Ah, I actually spotted this typo today while fixing another issue, so I went ahead and corrected it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27280#issuecomment-3292469347 From ghan at openjdk.org Mon Sep 15 14:38:54 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Mon, 15 Sep 2025 14:38:54 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: <2FOqadscYG1kBv_BojGeGg5HxPM_JKJN5fy2rlFplpQ=.f0506803-1aad-4656-8e7d-183c6912da24@github.com> References: <2FOqadscYG1kBv_BojGeGg5HxPM_JKJN5fy2rlFplpQ=.f0506803-1aad-4656-8e7d-183c6912da24@github.com> Message-ID: On Mon, 15 Sep 2025 14:27:49 GMT, Chen Liang wrote: >> trivial fix > > Since there is a behavioral change, please let me run CI tests before sponsoring. Also note point 7 in https://openjdk.org/guide/#life-of-a-pr, that you should leave sufficient time for reviewers before typing `/integrate`. Thanks! @liach Ah, I see ? I initially thought this was a trivial fix. I?ll wait for the CI tests to complete and give reviewers sufficient time before requesting sponsorship. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27280#issuecomment-3292504685 From liach at openjdk.org Mon Sep 15 15:08:59 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 15:08:59 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com> On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. Is `constantPoolOop` in `test/lib/jdk/test/lib/hprof/HprofParser.java` related to this removed field? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292670063 From phubner at openjdk.org Mon Sep 15 15:25:54 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Mon, 15 Sep 2025 15:25:54 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com> References: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com> Message-ID: On Mon, 15 Sep 2025 15:05:25 GMT, Chen Liang wrote: > Is `constantPoolOop` in `test/lib/jdk/test/lib/hprof/HprofParser.java` related to this removed field? I'm not sure, I came across this file as well and could not determine if it was an old artefact or not. I had a look at the log message and cross-referenced with HotSpot, and I also went digging in the commit messages, but I could not find anything fruitful. Considering it uses a wildcard and does not reference `sun.reflect.ConstantPool` or `jdk.internal.reflect.ConstantPool` leads me to believe this might be something else, most likely dead code. Many tiers of tests pass. I'm happy to open an issue if you think it's worth looking into. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292742093 From liach at openjdk.org Mon Sep 15 16:06:30 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 16:06:30 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. The removal of this field looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225353180 From coleenp at openjdk.org Mon Sep 15 16:06:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 16:06:31 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. ConstantPool in the JVM metadata used to be called constantPoolOop, so I think that's what it's looking to not find. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292895168 From darcy at openjdk.org Mon Sep 15 16:26:06 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 15 Sep 2025 16:26:06 GMT Subject: Integrated: 8367382: Expand use of representation equivalence terminology In-Reply-To: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> References: <_STBTOJo0EAh3Lc00KWuEzmr82ffZ62INspXr0tFwXc=.66ad1183-111c-43bc-8ced-0d6465e85b3c@github.com> Message-ID: On Thu, 11 Sep 2025 17:56:29 GMT, Joe Darcy wrote: > Small doc enhancement to use the term "representation equivalence" in a few more locations. This pull request has now been integrated. Changeset: 58c9fbc9 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/58c9fbc93db6c27b00d1e53d7ee8bf6e382eea82 Stats: 26 lines in 3 files changed: 24 ins; 0 del; 2 mod 8367382: Expand use of representation equivalence terminology Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/27232 From alanb at openjdk.org Mon Sep 15 16:40:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Sep 2025 16:40:09 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 14:09:58 GMT, Alan Bateman wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. > > As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run. > @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this. I think it's okay, and good for testing. I went through the relauncher closely, just not 100% sure of the quoting in the Windows implementation so I'm hoping Roger will have a few mins to scan that function. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3293033509 From alanb at openjdk.org Mon Sep 15 16:40:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Sep 2025 16:40:11 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:13:04 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove debug code src/java.base/windows/native/launcher/relauncher.c line 40: > 38: static char* launcher_args[] = LAUNCHER_ARGS; > 39: > 40: char* quote_argument(char* arg) { @RogerRiggs Would you mind scanning the quote_argument in the Windows launcher? You've had to deal with this in the process code and I think good to get another set of eyes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2349554917 From darcy at openjdk.org Mon Sep 15 16:54:11 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 15 Sep 2025 16:54:11 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v13] In-Reply-To: <8HZeA3EYJ7CqNxlQnUAxFCwU_Aqehf01H0YaOFQgptg=.910d8f19-b5b0-4f00-8404-9368bf6ac20e@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> <8HZeA3EYJ7CqNxlQnUAxFCwU_Aqehf01H0YaOFQgptg=.910d8f19-b5b0-4f00-8404-9368bf6ac20e@github.com> Message-ID: On Mon, 15 Sep 2025 07:39:00 GMT, fabioromano1 wrote: >> A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Optimization HI @fabioromano1, Ah, I haven't worked on that code for exact divide in a while! For some historical context, the method was added as part of JSR 13, Decimal Arithmetic Enhancement, in JDK 5. A fuller derivation of the old bound is discussed in: Fixed, Floating, and Exact Computation with Java's BigDecimalFixed, Floating, and Exact Computation with Java's BigDecimal Dr. Dobb's Journal ? Jun 1, 2004 https://web.archive.org/web/20210505132021/http://www.drdobbs.com/jvm/fixed-floating-and-exact-computation-wit/184405721 At the time I wrote the code, I looked around at the usual sources, Knuth, etc. and asked around for a bound of decimal digits of 1/b if 1/b is representable, but didn't find anything. I see you're still revising the implementation. Once this settles down, a review comment from me will be "restore some textual discussion of what the algorithm is doing." For testing, I think it would be good to probe at some values where the old and new digit estimation techniques differ. Also, I think both @rgiulietti and myself look at this PR before it goes back; I'll adjust the reviewer count accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27271#issuecomment-3293076586 From liach at openjdk.org Mon Sep 15 17:26:43 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 17:26:43 GMT Subject: RFR: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: <88eszB1rjpsU1qxhLX1zuYJdBWoOuhQmkxtGSPAC1FY=.edeb42a8-638e-418a-b3ca-e67e1cedf592@github.com> On Mon, 15 Sep 2025 05:37:58 GMT, Guanqiang Han wrote: > trivial fix Tier 1-3 clear. I will sponsor if there is no more review later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27280#issuecomment-3293195268 From rriggs at openjdk.org Mon Sep 15 17:33:26 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Sep 2025 17:33:26 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 16:35:49 GMT, Alan Bateman wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove debug code > > src/java.base/windows/native/launcher/relauncher.c line 40: > >> 38: static char* launcher_args[] = LAUNCHER_ARGS; >> 39: >> 40: char* quote_argument(char* arg) { > > @RogerRiggs Would you mind scanning the quote_argument in the Windows launcher? You've had to deal with this in the process code and I think good to get another set of eyes. Looks looks good. The algorithm in the windows version of ProcessImpl.java is the almost the same but the implementation is slightly different. But the result is the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2349634869 From rriggs at openjdk.org Mon Sep 15 17:33:30 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Sep 2025 17:33:30 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:13:04 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove debug code src/java.base/windows/native/launcher/relauncher.c line 79: > 77: backslashes = 0; > 78: } else { > 79: // Backslashes not preceeding a quote is copied without escaping is -> are src/java.base/windows/native/launcher/relauncher.c line 153: > 151: } > 152: > 153: // Our executable name (should not be quoted) ok here, because the full path is being explicitly passed to CreateProcess. If the command line is to be parsed and the executable path contains a space, CreateProcess does say it should be quoted. It would be good to have a test case with a space in the executable path. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2349635960 PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2349667061 From jsjolen at openjdk.org Mon Sep 15 17:44:39 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 15 Sep 2025 17:44:39 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. Looks good to me! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225668786 From duke at openjdk.org Mon Sep 15 18:01:49 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 15 Sep 2025 18:01:49 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v13] In-Reply-To: References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> <8HZeA3EYJ7CqNxlQnUAxFCwU_Aqehf01H0YaOFQgptg=.910d8f19-b5b0-4f00-8404-9368bf6ac20e@github.com> Message-ID: <71itIpqt3DV29ilODyznS4Km05HXwLX89oEBqK59zCU=.c285a502-75dc-4a43-9af1-3988c71da66c@github.com> On Mon, 15 Sep 2025 16:50:03 GMT, Joe Darcy wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimization > > HI @fabioromano1, > Ah, I haven't worked on that code for exact divide in a while! > For some historical context, the method was added as part of JSR 13, Decimal Arithmetic Enhancement, in JDK 5. A fuller derivation of the old bound is discussed in: > > Fixed, Floating, and Exact Computation with Java's BigDecimalFixed, Floating, and Exact Computation with Java's BigDecimal > Dr. Dobb's Journal ? Jun 1, 2004 > https://web.archive.org/web/20210505132021/http://www.drdobbs.com/jvm/fixed-floating-and-exact-computation-wit/184405721 > > At the time I wrote the code, I looked around at the usual sources, Knuth, etc. and asked around for a bound of decimal digits of 1/b if 1/b is representable, but didn't find anything. > > I see you're still revising the implementation. Once this settles down, a review comment from me will be "restore some textual discussion of what the algorithm is doing." > > For testing, I think it would be good to probe at some values where the old and new digit estimation techniques differ. > > Also, I think both @rgiulietti and myself look at this PR before it goes back; I'll adjust the reviewer count accordingly. @jddarcy The technique used here is the following: take $a/b$, compute $b' = b/(2^i 5^j)$, where $i = \max(n \in N \mid b \equiv 0 \mod 2^n)$ and $j = \max(n \in N \mid b \equiv 0 \mod 5^n)$. If $a \not\equiv 0 \mod b'$, then $a/b$ is not a finite decimal number. Otherwise: - if $i \le j$, then $a/b = (a/b')*2^{j-i} * 10^{-j}$; - if $i > j$, then $a/b = (a/b')*5^{j-i} * 10^{-i}$. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27271#issuecomment-3293326363 From amenkov at openjdk.org Mon Sep 15 19:15:26 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 15 Sep 2025 19:15:26 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. Looks good I was sure HeapDumper also uses FilteredJavaFieldStream to exclude constantPoolOop field, but it doesn't (I don't remember when it changed and why we didn't have issue with it) ------------- Marked as reviewed by amenkov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225947841 From rriggs at openjdk.org Mon Sep 15 19:27:18 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Sep 2025 19:27:18 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v8] In-Reply-To: References: Message-ID: <9R-KgStyY7YeTkB-C0NFQz5BfLdvtkjdT2eoB1hmz6o=.4ce81730-c3d8-4366-90bc-c48ac78f1dfe@github.com> > The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. > > The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. > > The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Monor improvements to javadoc, move close() near the constructor to make it more prominent in the javadoc. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26649/files - new: https://git.openjdk.org/jdk/pull/26649/files/174fc1d2..e35b8fc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=06-07 Stats: 149 lines in 1 file changed: 72 ins; 74 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26649.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649 PR: https://git.openjdk.org/jdk/pull/26649 From jlu at openjdk.org Mon Sep 15 21:10:16 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Sep 2025 21:10:16 GMT Subject: RFR: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes [v3] In-Reply-To: References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: On Thu, 11 Sep 2025 22:36:28 GMT, Justin Lu wrote: >> Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Reflect Iris's comments: capitalize JDK RI Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27233#issuecomment-3293958996 From jlu at openjdk.org Mon Sep 15 21:14:21 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Sep 2025 21:14:21 GMT Subject: Integrated: 8367237: Thread-Safety Usage Warning for java.text.Collator Classes In-Reply-To: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> References: <57DZjU9LPd8-B8c6m-Bgl_yypDzdfZU7J7DkJ-oSWc4=.59865341-ee4c-4af0-9d0a-a76953920101@github.com> Message-ID: On Thu, 11 Sep 2025 18:58:46 GMT, Justin Lu wrote: > Please review this PR which is a documentation change to make apparent the recommended approach for using Collator & RuleBasedCollator in a multi threaded environment via an implNote. The original issue and CSR have additional context. This pull request has now been integrated. Changeset: 64155dfa Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/64155dfac068cf01bcab6adb401b360499f33a5f Stats: 17 lines in 2 files changed: 10 ins; 4 del; 3 mod 8367237: Thread-Safety Usage Warning for java.text.Collator Classes Reviewed-by: iris, naoto ------------- PR: https://git.openjdk.org/jdk/pull/27233 From jlu at openjdk.org Mon Sep 15 21:25:00 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Sep 2025 21:25:00 GMT Subject: RFR: 8367703: Unneeded cast in java.text.DigitList.append Message-ID: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> During parse routines, DecimalFormat uses DigitList to append digits from the parsed text. Note that `digit` is always the int value 0 through 9 (and subsequently the code point 48 through 57) when passed to `append`. Currently, `append` accepts a char which forces an int -> char -> byte conversion to be stored in `digits`. This can be simplified to int -> byte if the parameter type for the method is updated. The two call sites can safely make this swap. Tiers 1-3 and java.text JCK tests continue to pass with this change. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/27300/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27300&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367703 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27300.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27300/head:pull/27300 PR: https://git.openjdk.org/jdk/pull/27300 From duke at openjdk.org Mon Sep 15 21:36:22 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 15 Sep 2025 21:36:22 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: <2LFahCvR7vDtTC9YVY55btRZRcTkFhfZvtX8-8IKk3Q=.8745c348-3ed3-46d4-a846-3c5adbe45c1d@github.com> References: <2LFahCvR7vDtTC9YVY55btRZRcTkFhfZvtX8-8IKk3Q=.8745c348-3ed3-46d4-a846-3c5adbe45c1d@github.com> Message-ID: On Fri, 12 Sep 2025 15:48:16 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak test. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 381: > >> 379: /** Returns whether a resource exists in the given module. */ >> 380: boolean containsResource(String moduleName, String resourcePath) { >> 381: // This method is tuned for cases where resources are likely to NOT > > I think this sentence can move to the method description. Also I'm not sure about saying "NOT exist" as it's really just an existence check. The system ModuleFinder find method will mostly be asked to locate resources that are in module packages so they will exist. That's not what I was seeing in the logging for the benchmark. >10,000 lookups, with about 20 that existed. Now, obviously if the benchmark is deliberately pushing non-existent resources, then it's not typical, but these were things like "button.gif" being searched for in all modules from the Swing code by the look of it. I don't mind removing this if this sort of behaviour isn't normal, or I can reword it to warn about the _possibility_ of lots of missing resources. What this is here for is so that a future maintainer doesn't optimise/modify it with the assumption that finding resources is the expected outcome. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2350177094 From duke at openjdk.org Mon Sep 15 21:42:11 2025 From: duke at openjdk.org (David Beaumont) Date: Mon, 15 Sep 2025 21:42:11 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: <_Ody3y1l61hto2Y_z1BMNTExSwlPzgCM5gu1ikfUEtU=.b3c45c52-7f7e-46e2-b697-d324d12ee15a@github.com> References: <_Ody3y1l61hto2Y_z1BMNTExSwlPzgCM5gu1ikfUEtU=.b3c45c52-7f7e-46e2-b697-d324d12ee15a@github.com> Message-ID: On Fri, 12 Sep 2025 15:42:24 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak test. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 360: > >> 358: // underlying jimage, but can only reliably return resource nodes. >> 359: if (moduleName.indexOf('/') >= 0) { >> 360: return null; > > Can you explain this further? We can't have a "/' in the module name at the language or API level. We could at the class level but there is likely a lot of work required in jimage, jlink and elsewhere if we ever allowed "/" in a module name. So right now, it would be a IAE if a call if invoking this with a "/" in the module name. Do you mean explain it in this review thread, or in the code comment? I know module names shouldn't have a '/' in, but were someone to call it with such, then the constructed path could become valid (e.g. module name="java.base/java", resource path="lang/Object.class". Since I wasn't sure which of the callers can be trusted to pass only valid module names, I didn't want to make it an exception in case I caused something to blow up somewhere else. I'm happy to make it an IAE, I'm just trying to avoid code paths where this API gets given invalid input, but is fooled into giving back real data. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2350185259 From rriggs at openjdk.org Mon Sep 15 21:47:11 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Sep 2025 21:47:11 GMT Subject: RFR: 8367703: Unneeded cast in java.text.DigitList.append In-Reply-To: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> References: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> Message-ID: On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote: > During parse routines, DecimalFormat uses DigitList to append digits from the parsed text. > > Note that `digit` is always the int value 0 through 9 (and subsequently the code point 48 through 57) when passed to `append`. > > Currently, `append` accepts a char which forces an int -> char -> byte conversion to be stored in `digits`. This can be simplified to int -> byte if the parameter type for the method is updated. The two call sites can safely make this swap. > > Tiers 1-3 and java.text JCK tests continue to pass with this change. Is there any observable/measureable performance difference? The byte type is a bit of a hack, while char is semantically more precise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27300#issuecomment-3294063823 From prappo at openjdk.org Mon Sep 15 22:02:44 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 15 Sep 2025 22:02:44 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** Message-ID: Please review this documentation-only change, which I believe does **NOT** require CSR. The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: * used a comma separator for some big integer values, to improve readability; * fixed a few typos and grammar. While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) Are there any cases here where that distinction matters? * In many cases, the following phrase is used throughout documentation: > positive or negative While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". --------- ### Progress - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) - [x] Change must not contain extraneous whitespace - [x] Commit message must refer to an issue ### Reviewing
Using git Checkout this PR locally: \ `$ git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296` \ `$ git checkout pull/27296` Update a local copy of the PR: \ `$ git checkout pull/27296` \ `$ git pull https://git.openjdk.org/jdk.git pull/27296/head`
Using Skara CLI tools Checkout this PR locally: \ `$ git pr checkout 27296` View PR using the GUI difftool: \ `$ git pr show -t 27296`
Using diff file Download this PR as a diff file: \ https://git.openjdk.org/jdk/pull/27296.diff
------------- Commit messages: - Use comma as a decimal separator - Fix Duration.abs - Initial commit Changes: https://git.openjdk.org/jdk/pull/27296/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367704 Stats: 26 lines in 6 files changed: 0 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/27296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296 PR: https://git.openjdk.org/jdk/pull/27296 From prappo at openjdk.org Mon Sep 15 22:31:28 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 15 Sep 2025 22:31:28 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v2] In-Reply-To: References: Message-ID: > Please review this documentation-only change, which I believe does **NOT** require CSR. > > The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: > > * used a comma separator for some big integer values, to improve readability; > * fixed a few typos and grammar. > > While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. > > * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? > > Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) > > Are there any cases here where that distinction matters? > > * In many cases, the following phrase is used throughout documentation: > > > positive or negative > > While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? > > * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296` \ > `$ git checkout pull/27296` > > Update a local copy of the PR: \ > `$ git checkout pull/27296` \ > `$ git pull https://git.openjdk.org/jdk.git pull/27296/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 27296` > > View PR using the GUI difftool: \ > `$ git pr show -t 27296` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/27296.diff > >
Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Extra typos and decimal separator ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27296/files - new: https://git.openjdk.org/jdk/pull/27296/files/540e48e1..4d8aadf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=00-01 Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296 PR: https://git.openjdk.org/jdk/pull/27296 From jlu at openjdk.org Mon Sep 15 22:39:12 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Sep 2025 22:39:12 GMT Subject: RFR: 8367703: Unneeded cast in java.text.DigitList.append In-Reply-To: References: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> Message-ID: On Mon, 15 Sep 2025 21:44:35 GMT, Roger Riggs wrote: > Is there any observable/measureable performance difference? The byte type is a bit of a hack, while char is semantically more precise. There is negligible performance impact. I filed this change not for performance, but rather simplifying the code path for readability because in the domain of DigitList, `digits` is a byte array and always composed of code points 48 to 57. With this context, passing it directly as a byte avoided an extra level of conversion and should be reasonable to the reader. In general, I understand the result of `(digit + '0')` as a char is semantically more precise; I can withdraw this PR if you think it hurts readability (since the goal is the opposite of that). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27300#issuecomment-3294205443 From iklam at openjdk.org Mon Sep 15 23:20:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Sep 2025 23:20:47 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27024/files - new: https://git.openjdk.org/jdk/pull/27024/files/5b71ce80..b1ef47dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From acobbs at openjdk.org Tue Sep 16 01:49:39 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 16 Sep 2025 01:49:39 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression Message-ID: This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. Summary of code changes: * Add new warning and associated lint category `"suppression"` * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category ------------- Commit messages: - Add clarifying comment. - Merge branch 'master' into JDK-8344159 - Change inner class name to avoid shadowing superclass name. - Add a couple of code clarification comments. - Refactor test to avoid requiring changes to TestRunner. - Remove unnecessary -Xlint:-suppression flags. - Minor cleanups. - Add OPTIONS, PATH, and SUPPRESSION to the regression test. - Minor regression test cleanups. - Minor comment tweaks. - ... and 120 more: https://git.openjdk.org/jdk/compare/11cdafb8...e3283ba9 Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344159 Stats: 1661 lines in 33 files changed: 1485 ins; 51 del; 125 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167 From fyang at openjdk.org Tue Sep 16 06:06:23 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 16 Sep 2025 06:06:23 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: <-D3Oiz-fmDudrEt2zZDa40Xff-Z4DP5GBWhts-CxPsY=.ea2ea9d6-49e6-4973-b4d2-cc1e0201f3c8@github.com> On Thu, 11 Sep 2025 07:24:13 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review > > That test failure in windows-x64 is a shenandoah timeout that looks unrelated. @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3295662846 From alanb at openjdk.org Tue Sep 16 06:19:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Sep 2025 06:19:13 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: <_Ody3y1l61hto2Y_z1BMNTExSwlPzgCM5gu1ikfUEtU=.b3c45c52-7f7e-46e2-b697-d324d12ee15a@github.com> Message-ID: On Mon, 15 Sep 2025 21:38:29 GMT, David Beaumont wrote: >> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 360: >> >>> 358: // underlying jimage, but can only reliably return resource nodes. >>> 359: if (moduleName.indexOf('/') >= 0) { >>> 360: return null; >> >> Can you explain this further? We can't have a "/' in the module name at the language or API level. We could at the class level but there is likely a lot of work required in jimage, jlink and elsewhere if we ever allowed "/" in a module name. So right now, it would be a IAE if a call if invoking this with a "/" in the module name. > > Do you mean explain it in this review thread, or in the code comment? > > I know module names shouldn't have a '/' in, but were someone to call it with such, then the constructed path could become valid (e.g. module name="java.base/java", resource path="lang/Object.class". Since I wasn't sure which of the callers can be trusted to pass only valid module names, I didn't want to make it an exception in case I caused something to blow up somewhere else. > > I'm happy to make it an IAE, I'm just trying to avoid code paths where this API gets given invalid input, but is fooled into giving back real data. If this is called with "/" in a module name then it means we've got a bug somewhere. So I think the IAE would help find that bug quicker. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2350977385 From epeter at openjdk.org Tue Sep 16 06:28:24 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 16 Sep 2025 06:28:24 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v13] In-Reply-To: References: Message-ID: <2DmjQ5OVBp_bHyQl1gMIB6-vNn8AgXjHbK2Geu9pWr8=.c08a85a0-c63e-4d31-9140-64c44c7b8cd6@github.com> On Mon, 15 Sep 2025 05:43:11 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request incrementally with one additional commit since the last revision: > > Add an IR rule for vector mask cast operation @erifan Nice work on the benchmark refactor! And thanks for the other updates. I'll run some testing now, should take about 24h. ------------- PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-3227664072 From alanb at openjdk.org Tue Sep 16 06:40:35 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Sep 2025 06:40:35 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: <2LFahCvR7vDtTC9YVY55btRZRcTkFhfZvtX8-8IKk3Q=.8745c348-3ed3-46d4-a846-3c5adbe45c1d@github.com> Message-ID: On Mon, 15 Sep 2025 21:33:15 GMT, David Beaumont wrote: >> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 381: >> >>> 379: /** Returns whether a resource exists in the given module. */ >>> 380: boolean containsResource(String moduleName, String resourcePath) { >>> 381: // This method is tuned for cases where resources are likely to NOT >> >> I think this sentence can move to the method description. Also I'm not sure about saying "NOT exist" as it's really just an existence check. The system ModuleFinder find method will mostly be asked to locate resources that are in module packages so they will exist. > > That's not what I was seeing in the logging for the benchmark. >10,000 lookups, with about 20 that existed. > Now, obviously if the benchmark is deliberately pushing non-existent resources, then it's not typical, but these were things like "button.gif" being searched for in all modules from the Swing code by the look of it. > I don't mind removing this if this sort of behaviour isn't normal, or I can reword it to warn about the _possibility_ of lots of missing resources. What this is here for is so that a future maintainer doesn't optimise/modify it with the assumption that finding resources is the expected outcome. The comment was about putting the useful comment into the method description, so not suggesting changing the method body. As regards the benchmark then it's just a Class.getResource usage from code on the class path. The class loader delegation means the built-in class loaders are being called to locate a resource that doesn't map to a module package. This is the slow case and forces all modules to be opened to find the resource. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2351040103 From tschatzl at openjdk.org Tue Sep 16 07:36:40 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 07:36:40 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 07:24:13 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review > > That test failure in windows-x64 is a shenandoah timeout that looks unrelated. > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3296253540 From fyang at openjdk.org Tue Sep 16 07:41:46 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 16 Sep 2025 07:41:46 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 07:33:18 GMT, Thomas Schatzl wrote: > > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) > > This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. Yes, sure! The purpose is to minimize the difference to avoid possible issues in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3296286316 From adinn at openjdk.org Tue Sep 16 08:41:23 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Sep 2025 08:41:23 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." Just for clarity you might want to update the PR description to state that this PR "annotates a single aot initializable class, jdk.internal.math.MathUtils (also the object hierarchy root class, Object.class, which has no associated aot initialization but is required for completeness)". More classes will be added in future PRs. Also, the PR description refers to @AOTSafeAnnotation -- do you mean @AOTSafeClassInitializer? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3296618017 PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3296635606 From adinn at openjdk.org Tue Sep 16 09:28:24 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Sep 2025 09:28:24 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." src/hotspot/share/cds/aotMetaspace.cpp line 806: > 804: AOTClassInitializer::init_test_class(CHECK); > 805: > 806: if (CDSConfig::is_dumping_final_static_archive()) { What is the reason for moving this earlier to before link_all_loaded_classes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2351659530 From phubner at openjdk.org Tue Sep 16 09:35:02 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 09:35:02 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8365858 - Merge branch 'master' into JDK-8365858 - Fix typo. - Refactor to purely use injected fields. - Remove FilteredJavaFieldStream and usages. - Remove constantPoolOop from Java code. - Make constantPoolOop a hidden vmholder field. ------------- Changes: https://git.openjdk.org/jdk/pull/27209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27209&range=01 Stats: 194 lines in 9 files changed: 9 ins; 166 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/27209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27209/head:pull/27209 PR: https://git.openjdk.org/jdk/pull/27209 From phubner at openjdk.org Tue Sep 16 09:35:03 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 09:35:03 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 16:00:41 GMT, Coleen Phillimore wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > ConstantPool in the JVM metadata used to be called constantPoolOop, so I think that's what it's looking to not find. Thanks for the reviews, @coleenp @liach @jdksjolen @alexmenkov. I've merged in the latest mainline which had a merge commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3297070955 From duke at openjdk.org Tue Sep 16 09:55:06 2025 From: duke at openjdk.org (Johny Jose) Date: Tue, 16 Sep 2025 09:55:06 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:01:06 GMT, Johny Jose wrote: >> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes Changes updated as per the review comments in JBS ------------- PR Review: https://git.openjdk.org/jdk/pull/26815#pullrequestreview-3228806170 From duke at openjdk.org Tue Sep 16 10:01:58 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 16 Sep 2025 10:01:58 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: <_Ody3y1l61hto2Y_z1BMNTExSwlPzgCM5gu1ikfUEtU=.b3c45c52-7f7e-46e2-b697-d324d12ee15a@github.com> Message-ID: <8VZXPZMGREx9MgbIDXGi3HoeedbLfFGf12rtpVhBJIE=.8778b33f-a498-4df9-9a6d-9ae1e61ad994@github.com> On Tue, 16 Sep 2025 06:16:44 GMT, Alan Bateman wrote: >> Do you mean explain it in this review thread, or in the code comment? >> >> I know module names shouldn't have a '/' in, but were someone to call it with such, then the constructed path could become valid (e.g. module name="java.base/java", resource path="lang/Object.class". Since I wasn't sure which of the callers can be trusted to pass only valid module names, I didn't want to make it an exception in case I caused something to blow up somewhere else. >> >> I'm happy to make it an IAE, I'm just trying to avoid code paths where this API gets given invalid input, but is fooled into giving back real data. > > If this is called with "/" in a module name then it means we've got a bug somewhere. So I think the IAE would help find that bug quicker. Fair enough. I'll look at the callers and see if there's any route by which an "invalid" module name could appear. Though I already have to assume nobody uses "modules" or "packages" as the module name. >> That's not what I was seeing in the logging for the benchmark. >10,000 lookups, with about 20 that existed. >> Now, obviously if the benchmark is deliberately pushing non-existent resources, then it's not typical, but these were things like "button.gif" being searched for in all modules from the Swing code by the look of it. >> I don't mind removing this if this sort of behaviour isn't normal, or I can reword it to warn about the _possibility_ of lots of missing resources. What this is here for is so that a future maintainer doesn't optimise/modify it with the assumption that finding resources is the expected outcome. > > The comment was about putting the useful comment into the method description, so not suggesting changing the method body. > > As regards the benchmark then it's just a Class.getResource usage from code on the class path. The class loader delegation means the built-in class loaders are being called to locate a resource that doesn't map to a module package. This is the slow case and forces all modules to be opened to find the resource. I see, I'll move it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2351762939 PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2351757878 From duke at openjdk.org Tue Sep 16 10:02:00 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 16 Sep 2025 10:02:00 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 15:00:38 GMT, Jaikiran Pai wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak test. > > test/jdk/jdk/internal/jimage/ImageReaderTest.java line 163: > >> 161: // Or module names/paths to be empty. >> 162: "'':modfoo/com/foo/Alpha.class", >> 163: "modfoo:''"}) > > Does the use of `'` literals in that string translate to an empty value for module/resource path? I haven't checked myself. Yes, without it you get null. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2351754572 From adinn at openjdk.org Tue Sep 16 10:06:46 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Sep 2025 10:06:46 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." > This annotation is awfully similar to @AOTSafeAnnotation, and I am not sure if we need both Maybe we do want both. @AOTSafeAnnotation is weaker than @AOTInitialize because the former only initializes classes optionally when we find it is needed. If we only had @AOTInitialize then we would lose that optionality. It may not make much difference now -- we probably only have these annotations for JDK classes that would need to be class-inited whatever the training regime. However, as we expand use of the annotation might we risk initing classes and including their state in the archive without necessarily seeing any benefit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3297343820 From duke at openjdk.org Tue Sep 16 10:08:55 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 16 Sep 2025 10:08:55 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: <8VZXPZMGREx9MgbIDXGi3HoeedbLfFGf12rtpVhBJIE=.8778b33f-a498-4df9-9a6d-9ae1e61ad994@github.com> References: <_Ody3y1l61hto2Y_z1BMNTExSwlPzgCM5gu1ikfUEtU=.b3c45c52-7f7e-46e2-b697-d324d12ee15a@github.com> <8VZXPZMGREx9MgbIDXGi3HoeedbLfFGf12rtpVhBJIE=.8778b33f-a498-4df9-9a6d-9ae1e61ad994@github.com> Message-ID: On Tue, 16 Sep 2025 09:59:02 GMT, David Beaumont wrote: >> If this is called with "/" in a module name then it means we've got a bug somewhere. So I think the IAE would help find that bug quicker. > > Fair enough. I'll look at the callers and see if there's any route by which an "invalid" module name could appear. Though I already have to assume nobody uses "modules" or "packages" as the module name. It looks like ModuleDescriptor.Builder could be used in non-strict mode to get a module with a '/' in its name which might be passed to this code. And as this is a public class (albeit internal) it's possible someone does this. So adding an IAE would make things blow up in a way it didn't before. I assume you're happy with this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2351790934 From duke at openjdk.org Tue Sep 16 10:31:39 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 16 Sep 2025 10:31:39 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v9] In-Reply-To: References: Message-ID: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Feedback tweaks. Comment and IAE. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/e2ead2a6..1d5c5bb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=07-08 Stats: 14 lines in 1 file changed: 8 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From alanb at openjdk.org Tue Sep 16 11:49:30 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Sep 2025 11:49:30 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v8] In-Reply-To: References: <_Ody3y1l61hto2Y_z1BMNTExSwlPzgCM5gu1ikfUEtU=.b3c45c52-7f7e-46e2-b697-d324d12ee15a@github.com> <8VZXPZMGREx9MgbIDXGi3HoeedbLfFGf12rtpVhBJIE=.8778b33f-a498-4df9-9a6d-9ae1e61ad994@github.com> Message-ID: On Tue, 16 Sep 2025 10:06:21 GMT, David Beaumont wrote: >> Fair enough. I'll look at the callers and see if there's any route by which an "invalid" module name could appear. Though I already have to assume nobody uses "modules" or "packages" as the module name. > > It looks like ModuleDescriptor.Builder could be used in non-strict mode to get a module with a '/' in its name which might be passed to this code. And as this is a public class (albeit internal) it's possible someone does this. > So adding an IAE would make things blow up in a way it didn't before. I assume you're happy with this. The strict mode is for the API, it is aligned with the language, so can't have modules named "package" or modules with "/" in the name. It's more lenient in class files where you can use any name or character. There are a few exceptions (@ : and control chars) that require escaping. This is the "non-strict" mode that you see in the code. In practical terms it would require changes in several areas to support module names containing "/" in the name. The launcher is just one of several places that would be tripped up. We can create an issue in JBS to track that but is low priority. For now, I think it's okay to reject module name containing "/". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27203#discussion_r2352169434 From jsjolen at openjdk.org Tue Sep 16 12:21:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 12:21:17 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: <8fizZwH_W2n31RiJAJZAxU0dMFs3UaLU0Uk-yoTHST0=.7ab516ac-e506-4635-b08e-f4a3af4cfb7b@github.com> On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8365858 > - Merge branch 'master' into JDK-8365858 > - Fix typo. > - Refactor to purely use injected fields. > - Remove FilteredJavaFieldStream and usages. > - Remove constantPoolOop from Java code. > - Make constantPoolOop a hidden vmholder field. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3229698749 From duke at openjdk.org Tue Sep 16 13:01:34 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 16 Sep 2025 13:01:34 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v10] In-Reply-To: References: Message-ID: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Update tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27203/files - new: https://git.openjdk.org/jdk/pull/27203/files/1d5c5bb4..49cc2a3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27203&range=08-09 Stats: 23 lines in 1 file changed: 15 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27203/head:pull/27203 PR: https://git.openjdk.org/jdk/pull/27203 From erikj at openjdk.org Tue Sep 16 13:04:16 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 16 Sep 2025 13:04:16 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression In-Reply-To: References: Message-ID: On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote: > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25167#pullrequestreview-3229887954 From jpai at openjdk.org Tue Sep 16 13:20:23 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 16 Sep 2025 13:20:23 GMT Subject: RFR: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null [v3] In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 09:35:54 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? >> >> As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. >> >> The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. >> >> tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > move the check to Shutdown.exit() Thank you all for the reviews. tier1, tier2 and tier3 testing completed without any failures. I'll go ahead and integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27270#issuecomment-3298718082 From jpai at openjdk.org Tue Sep 16 13:20:24 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 16 Sep 2025 13:20:24 GMT Subject: Integrated: 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 07:10:42 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8367597? > > As noted in that issue, on certain occasions, during shutdown of the JVM, the logging in `Runtime.exit()` generates a `NullPointerException`. The issue is due to the JVM not being fully initialized when (concurrently) the signal handler thread calls the `Runtime.exit()` code which then attempts to log a message. > > The commit in this PR skips the logging from `Runtime.exit()` if the JVM isn't fully initialized at that point in time. I've manually verified that this change indeed addresses the issue by running the same tests on the hosts where this was previously failing. No new regressions tests have been introduced given the nature of the issue. > > tier1 testing with this change completed without any related issues and additional tier testing is currently in progress. This pull request has now been integrated. Changeset: 0bc37059 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/0bc3705948b1bb8f327dc48c4dbd85d22d66f036 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8367597: Runtime.exit logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "m" is null Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/27270 From erikj at openjdk.org Tue Sep 16 13:55:23 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 16 Sep 2025 13:55:23 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression In-Reply-To: References: Message-ID: <81JqWQPRbafWl22IItWNL52faigZS1l31SXsD9Zq1EE=.b6d84001-edd9-443a-8ca7-555a81ae6af0@github.com> On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote: > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category > /label remove kulla I have removed kulla-dev from the bot configuration so the stuck label is now benign. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3298796516 From mbaesken at openjdk.org Tue Sep 16 13:57:49 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 16 Sep 2025 13:57:49 GMT Subject: RFR: 8367573: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_aix.c Message-ID: Similar to JDK-8367138 , we should add a JNI exception check to os_getCmdlineAndUserInfo on AIX . ------------- Commit messages: - JDK-8367573 Changes: https://git.openjdk.org/jdk/pull/27313/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27313&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367573 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27313.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27313/head:pull/27313 PR: https://git.openjdk.org/jdk/pull/27313 From rriggs at openjdk.org Tue Sep 16 14:15:22 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Sep 2025 14:15:22 GMT Subject: RFR: 8367573: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_aix.c In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 13:30:40 GMT, Matthias Baesken wrote: > Similar to JDK-8367138 , we should add a JNI exception check to os_getCmdlineAndUserInfo on AIX . looks good. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27313#pullrequestreview-3230214743 From alanb at openjdk.org Tue Sep 16 14:26:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Sep 2025 14:26:45 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v10] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 13:01:34 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Update tests. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27203#pullrequestreview-3230269897 From rriggs at openjdk.org Tue Sep 16 14:33:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Sep 2025 14:33:44 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v10] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 13:01:34 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Update tests. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27203#pullrequestreview-3230299748 From liach at openjdk.org Tue Sep 16 15:01:24 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Sep 2025 15:01:24 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8365858 > - Merge branch 'master' into JDK-8365858 > - Fix typo. > - Refactor to purely use injected fields. > - Remove FilteredJavaFieldStream and usages. > - Remove constantPoolOop from Java code. > - Make constantPoolOop a hidden vmholder field. Still looks good ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3230428037 From ghan at openjdk.org Tue Sep 16 15:01:36 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Tue, 16 Sep 2025 15:01:36 GMT Subject: Integrated: 8367619: String.format in outOfRangeException uses wrong format specifier for String argument In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:37:58 GMT, Guanqiang Han wrote: > trivial fix This pull request has now been integrated. Changeset: 58007c0b Author: Guanqiang Han Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/58007c0bcc03f4609ce202cfb9f89b8438055dac Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8367619: String.format in outOfRangeException uses wrong format specifier for String argument Reviewed-by: fandreuzzi, rriggs, liach ------------- PR: https://git.openjdk.org/jdk/pull/27280 From prappo at openjdk.org Tue Sep 16 16:10:44 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 16 Sep 2025 16:10:44 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v3] In-Reply-To: References: Message-ID: <8II7NdKUskPi_iiXwRaHLWXJoRnLNBh7E-rbG-vddj0=.531edce5-2d51-4db6-9072-496a36ef3241@github.com> > Please review this documentation-only change, which I believe does **NOT** require CSR. > > The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: > > * used a comma separator for some big integer values, to improve readability; > * fixed a few typos and grammar. > > While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. > > * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? > > Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) > > Are there any cases here where that distinction matters? > > * In many cases, the following phrase is used throughout documentation: > > > positive or negative > > While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? > > * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: A few more typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27296/files - new: https://git.openjdk.org/jdk/pull/27296/files/4d8aadf8..e58c5a4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296 PR: https://git.openjdk.org/jdk/pull/27296 From michael.osipov at innomotics.com Tue Sep 16 16:14:11 2025 From: michael.osipov at innomotics.com (Osipov, Michael (IN IT IN)) Date: Tue, 16 Sep 2025 18:14:11 +0200 Subject: Why is CompositeName used in JNDI/LDAP after all? Message-ID: Hi folks, consider this exception we had yesterday in production: > 11:54:13.120 [https-openssl-apr-0.0.0.0-8008-exec-3] ERROR c.s.l.c.s.s.a.impl.ADUserAccess - Active Directory connection error! > org.springframework.ldap.UncategorizedLdapException: Uncategorized exception occured during LDAP processing; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-03100836, problem 5012 (DIR_ERROR), data 0 > ]; remaining name 'CN=SmartLD // China Hub_ab1464c2a8e6,OU=Cloud Groups,OU=ACF TEST,DC=innomotics,DC=net' > at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:228) > at org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:824) >... > Caused by: javax.naming.NamingException: [LDAP: error code 1 - 000020D6: SvcErr: DSID-03100836, problem 5012 (DIR_ERROR), data 0 > ] > at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3305) > at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3211) > at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3002) > at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1062) > at com.sun.jndi.toolkit.ctx.ComponentContext.c_resolveIntermediate_nns(ComponentContext.java:168) > at com.sun.jndi.toolkit.ctx.AtomicContext.c_resolveIntermediate_nns(AtomicContext.java:359) > at com.sun.jndi.toolkit.ctx.ComponentContext.p_resolveIntermediate(ComponentContext.java:439) > at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:227) > at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) > at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) > at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) > at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source) CompsiteName splits on slash sending an invalid request to Active Directory. The method in question is javax.naming.directory.InitialDirContext# getAttributes(String name). I always assumed that the string value is parsed into an LDAP name via #getNameParser(""). Looking into the code I see that LdapCtx inherits from PartialCompositeDirContext using CompositeName which is unsuited for LDAP in general. At first, I considered this to be a conceptual bug and was about to report with you, but then found [1]. It explicitly says that: If your pass a string CompositeName is used. If you need exact results use LdapName. My question is: Why does an LDAP context have this conceptual pitfall? I mean, this approach does not compute for me logically. At the end, unless you exactly know what you are passing to as a string, you *always* have to go through LdapNameParser to be on the safe side. Michael [1] https://docs.oracle.com/javase/jndi/tutorial/beyond/names/syntax.html From phubner at openjdk.org Tue Sep 16 16:19:13 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 16:19:13 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8365858 > - Merge branch 'master' into JDK-8365858 > - Fix typo. > - Refactor to purely use injected fields. > - Remove FilteredJavaFieldStream and usages. > - Remove constantPoolOop from Java code. > - Make constantPoolOop a hidden vmholder field. Thanks for the reviews everyone. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3299475347 From msheppar at openjdk.org Tue Sep 16 16:20:18 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 16 Sep 2025 16:20:18 GMT Subject: RFR: 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:01:06 GMT, Johny Jose wrote: >> Increasing the count value of available objects to 6 (which is half the number of objects created). The failures were reported in macos which seems to take more time to clear the objects. Though majority runs has less values for objects (less than 4), in order to eliminate intermittent failures, raising the threshold values to 6 > > Johny Jose has updated the pull request incrementally with one additional commit since the last revision: > > Review changes The current approach should add a bit more consistency to the test. If you could oblige and run the test through the CI pipeline on --test-repeat 200 please Also on --test-repeat 200 run the test as part of its jdk_rmi test group And a final check run it in a tier3 job However, I would like to offer a possible enhancement on this approach If we look at the test's objectives and the structure. The test spawns 10 test client processes. They invoke a ping remote method call on the remote server This activates a lease. The lease is set to expire after 20 msecs Thus, it should be removed from the lease table A test is made on the lease table to check expiring leases have been purged. The test structure is subject to the process and thread scheduling variations of an OS. This allows indeterminate behaviour to exist, and as such we could look to reduce this execution variability. There is no guarantee that the spawned process will start executing immediately. Generally, this is the case on a lightly loaded machine, but one under significant load (as might be the case in a CI pipeline) that may not be the case ... thus, scheduling delays may occur. It we add some check that all clients have executed prior to testing the lease, that will add additional reliability to the leaseTable test. Thus, if the testing of the lease table is synchronised with the remote invocations, it is possible to create consistent conditions for the test. That is, to test the lease expiry and lease table removal after the last remote invocation has been made This requires using a CountDownLatch(NO_OF_CLIENTS), which is countdown for each remote invocation And the main thread await for the latch countdown. Thereafter the main thread sleeps for a period of time equal to the NO_OF__CLIENTS * LEASE_EXPIRY_TIME * GOOD_LUCK_FACTOR Thus the the check of the lease table is subject to the condition that all clients have made a remote invocation and that their leases have expired. Theoretically, the number of active leases should be zero, but retaining the current lease check condition is fine Thus the following could be added public class CheckLeaseLeak extends UnicastRemoteObject implements LeaseLeak { public CheckLeaseLeak() throws RemoteException { } public void ping () throws RemoteException { remoteCallsComplete.countDown(); } . . . private final static int ITERATIONS = 10; private final static int numberPingCalls = 0; private final static int CHECK_INTERVAL = 400; private final static int LEASE_VALUE = 20; private static final int NO_OF_CLIENTS = ITERATIONS; private static final int GOOD_LUCK_FACTOR = 2; . . . try { if (jvm.execute() != 0) { TestLibrary.bomb("Client process failed"); } } finally { jvm.destroy(); } } try { remoteCallsComplete.await(); System.out.println("remoteCallsComplete . . . "); } catch (InterruptedException intEx) { System.out.println("remoteCallsComplete.await interrupted . . . "); } Thread.sleep(NO_OF__CLIENTS * LEASE_EXPIRY_TIME * GOOD_LUCK_FACTOR); numLeft = getDGCLeaseTableSize(); . . . ------------- PR Comment: https://git.openjdk.org/jdk/pull/26815#issuecomment-3299476175 From naoto at openjdk.org Tue Sep 16 16:21:17 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 16 Sep 2025 16:21:17 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v3] In-Reply-To: <8II7NdKUskPi_iiXwRaHLWXJoRnLNBh7E-rbG-vddj0=.531edce5-2d51-4db6-9072-496a36ef3241@github.com> References: <8II7NdKUskPi_iiXwRaHLWXJoRnLNBh7E-rbG-vddj0=.531edce5-2d51-4db6-9072-496a36ef3241@github.com> Message-ID: On Tue, 16 Sep 2025 16:10:44 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > A few more typos LGTM. Some files need copyright bumps. As to "positive or negative", isn't zero signed in IEEE 754? ------------- PR Review: https://git.openjdk.org/jdk/pull/27296#pullrequestreview-3230759025 From duke at openjdk.org Tue Sep 16 16:22:21 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 16:22:21 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8365858 > - Merge branch 'master' into JDK-8365858 > - Fix typo. > - Refactor to purely use injected fields. > - Remove FilteredJavaFieldStream and usages. > - Remove constantPoolOop from Java code. > - Make constantPoolOop a hidden vmholder field. @Arraying Your change (at version 54bc0476fe86c9b1759fff8c0062069ff3e536fa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3299484854 From lancea at openjdk.org Tue Sep 16 16:22:21 2025 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 16 Sep 2025 16:22:21 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v8] In-Reply-To: <9R-KgStyY7YeTkB-C0NFQz5BfLdvtkjdT2eoB1hmz6o=.4ce81730-c3d8-4366-90bc-c48ac78f1dfe@github.com> References: <9R-KgStyY7YeTkB-C0NFQz5BfLdvtkjdT2eoB1hmz6o=.4ce81730-c3d8-4366-90bc-c48ac78f1dfe@github.com> Message-ID: On Mon, 15 Sep 2025 19:27:18 GMT, Roger Riggs wrote: >> The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. >> >> The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. >> >> The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Monor improvements to javadoc, move close() near the constructor > to make it more prominent in the javadoc. Thank you for tackling this Roger. I think your changes are in a good place ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26649#pullrequestreview-3230763198 From prappo at openjdk.org Tue Sep 16 16:29:21 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 16 Sep 2025 16:29:21 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v3] In-Reply-To: <8II7NdKUskPi_iiXwRaHLWXJoRnLNBh7E-rbG-vddj0=.531edce5-2d51-4db6-9072-496a36ef3241@github.com> References: <8II7NdKUskPi_iiXwRaHLWXJoRnLNBh7E-rbG-vddj0=.531edce5-2d51-4db6-9072-496a36ef3241@github.com> Message-ID: On Tue, 16 Sep 2025 16:10:44 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > A few more typos Thanks. > As to "positive or negative", isn't zero signed in IEEE 754? I might be missing something, but what does IEEE 754 have to do with this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3299509569 From prappo at openjdk.org Tue Sep 16 16:39:03 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 16 Sep 2025 16:39:03 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v4] In-Reply-To: References: Message-ID: > Please review this documentation-only change, which I believe does **NOT** require CSR. > > The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: > > * used a comma separator for some big integer values, to improve readability; > * fixed a few typos and grammar. > > While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. > > * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? > > Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) > > Are there any cases here where that distinction matters? > > * In many cases, the following phrase is used throughout documentation: > > > positive or negative > > While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? > > * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update src/java.base/share/classes/java/time/package-info.java due to e58c5a4c023 + update src/java.base/share/classes/java/time/temporal/ChronoField.java due to 4d8aadf8754 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27296/files - new: https://git.openjdk.org/jdk/pull/27296/files/e58c5a4c..d8510639 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296 PR: https://git.openjdk.org/jdk/pull/27296 From prappo at openjdk.org Tue Sep 16 16:46:11 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 16 Sep 2025 16:46:11 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v5] In-Reply-To: References: Message-ID: > Please review this documentation-only change, which I believe does **NOT** require CSR. > > The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: > > * used a comma separator for some big integer values, to improve readability; > * fixed a few typos and grammar. > > While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. > > * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? > > Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) > > Are there any cases here where that distinction matters? > > * In many cases, the following phrase is used throughout documentation: > > > positive or negative > > While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? > > * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/time/temporal/ChronoField.java Co-authored-by: Justin Lu ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27296/files - new: https://git.openjdk.org/jdk/pull/27296/files/d8510639..a9bd5cef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296 PR: https://git.openjdk.org/jdk/pull/27296 From jlu at openjdk.org Tue Sep 16 16:46:15 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 16 Sep 2025 16:46:15 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v3] In-Reply-To: <8II7NdKUskPi_iiXwRaHLWXJoRnLNBh7E-rbG-vddj0=.531edce5-2d51-4db6-9072-496a36ef3241@github.com> References: <8II7NdKUskPi_iiXwRaHLWXJoRnLNBh7E-rbG-vddj0=.531edce5-2d51-4db6-9072-496a36ef3241@github.com> Message-ID: On Tue, 16 Sep 2025 16:10:44 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > A few more typos src/java.base/share/classes/java/time/temporal/ChronoField.java line 602: > 600: * This is usually a fixed number of hours and minutes. > 601: * It is equivalent to the {@link ZoneOffset#getTotalSeconds() total amount} of the offset in seconds. > 602: * For example, during the winter Paris has an offset of {@code +01:00}, which is 3,600 seconds. Suggestion: * For example, during the winter, Paris has an offset of {@code +01:00}, which is 3,600 seconds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27296#discussion_r2353070935 From naoto at openjdk.org Tue Sep 16 16:55:48 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 16 Sep 2025 16:55:48 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v5] In-Reply-To: References: Message-ID: <3f1qjVna29A5zZQvXQd-Gm9EWI02LRbA4cWY5YACnPo=.e935917e-86fc-438d-8560-8a1fb13e602f@github.com> On Tue, 16 Sep 2025 16:46:11 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/time/temporal/ChronoField.java > > Co-authored-by: Justin Lu Looks good. > I might be missing something, but what does IEEE 754 have to do with this? I was simply mentioning there are cases where zeros are signed. Agree that adding zero here is clearer. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27296#pullrequestreview-3230898454 From prappo at openjdk.org Tue Sep 16 17:10:18 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 16 Sep 2025 17:10:18 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: References: Message-ID: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> > Please review this documentation-only change, which I believe does **NOT** require CSR. > > The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: > > * used a comma separator for some big integer values, to improve readability; > * fixed a few typos and grammar. > > While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. > > * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? > > Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) > > Are there any cases here where that distinction matters? > > * In many cases, the following phrase is used throughout documentation: > > > positive or negative > > While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? > > * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: An empty commit to kick GHA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27296/files - new: https://git.openjdk.org/jdk/pull/27296/files/a9bd5cef..9ce42070 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=04-05 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296 PR: https://git.openjdk.org/jdk/pull/27296 From iklam at openjdk.org Tue Sep 16 17:27:20 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:27:20 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v3] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added comment about the order of FinalImageRecipes::apply_recipes() vs link_all_loaded_classes() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27024/files - new: https://git.openjdk.org/jdk/pull/27024/files/b1ef47dc..15798558 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=01-02 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From iklam at openjdk.org Tue Sep 16 17:27:22 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:27:22 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: <57rG7_WaUKuvGF296n4V3HUC-tcnnnmLDxs77d1VhqY=.02396658-ea80-481a-a76f-994b8519aa6e@github.com> On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." > Just for clarity you might want to update the PR description to state that this PR "annotates a single aot initializable class, jdk.internal.math.MathUtils (also the object hierarchy root class, Object.class, which has no associated aot initialization but is required for completeness)". More classes will be added in future PRs. > Also, the PR description refers to @AOTSafeAnnotation -- do you mean @AOTSafeClassInitializer? I updated the PR description as suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3299677921 From iklam at openjdk.org Tue Sep 16 17:40:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:40:48 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added logging about @AOTSafeClassInitializer classes that have not been initialized ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27024/files - new: https://git.openjdk.org/jdk/pull/27024/files/15798558..24b52a49 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=02-03 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From iklam at openjdk.org Tue Sep 16 17:50:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:50:09 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:40:48 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added logging about @AOTSafeClassInitializer classes that have not been initialized > > This annotation is awfully similar to @AOTSafeClassInitializer, and I am not sure if we need both > > Maybe we do want both. @AOTSafeClassInitializer is weaker than @AOTInitialize because the former only initializes classes optionally when we find it is needed. If we only had @AOTInitialize then we would lose that optionality. It may not make much difference now -- we probably only have these annotations for JDK classes that would need to be class-inited whatever the training regime. However, as we expand use of the annotation might we risk initing classes and including their state in the archive without necessarily seeing any benefit? Yes, I think we can experiment with having both annotations for now. I added logging and found: java.util.stream.Collectors is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_LLL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_D is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_I is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_LLLLL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_DL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_LLLL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_IL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.VarHandleGuards is annotated with @AOTSafeClassInitializer but has not been initialized So I think the rules for choosing the annotations for class `C` is: - If it's certain that AOT-initialization of `C` is safe and beneficial (considering space/speed tradeoffs), use `@AOTInitialize` - If it's certain that AOT-initialization of `C` is safe, and it's necessary to preserve the effect of `C.` for correctness, use `@AOTSafeClassInitializer` We might prefer `@AOTSafeClassInitializer` if `C.` executes quickly (so there's no start-up benefit for AOT-initialization) but would produce a large amount of data that would increase the footprint of the AOT cache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3299749941 From iklam at openjdk.org Tue Sep 16 17:50:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:50:12 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:25:21 GMT, Andrew Dinn wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." > > src/hotspot/share/cds/aotMetaspace.cpp line 806: > >> 804: AOTClassInitializer::init_test_class(CHECK); >> 805: >> 806: if (CDSConfig::is_dumping_final_static_archive()) { > > What is the reason for moving this earlier to before link_all_loaded_classes? I added comment about the order of this code vs link_all_loaded_classes(). Before switching the order, I found that in some rare cases classes were removed from the AOT cache because they are unlinked after `FinalImageRecipes::apply_recipes()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2353226013 From rriggs at openjdk.org Tue Sep 16 18:46:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Sep 2025 18:46:55 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: <_Ua4Z82zmV3eVBGyQvrasBorN3Q84sPMQTTf5Oyne_I=.6c4d6a31-80de-4af1-8a15-ac7f921c3639@github.com> On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > An empty commit to kick GHA looks good. A CSR is needed due to the changes to the text that imply a change in semantics, for example, changing 'month" to "day". Even if they are viewed as being incorrect, it needs a thorough review. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27296#pullrequestreview-3231247517 PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3299926612 From darcy at openjdk.org Tue Sep 16 19:01:10 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 16 Sep 2025 19:01:10 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression In-Reply-To: References: Message-ID: On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote: > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Hi @archiecobbs , are there bugs filed to clean the causes of the warnings? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3299975129 From phubner at openjdk.org Tue Sep 16 19:20:57 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 19:20:57 GMT Subject: Integrated: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. This pull request has now been integrated. Changeset: b75e35cb Author: Paul H?bner Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/b75e35cb94d17a742d88f23dfd1b016c26a5e63c Stats: 194 lines in 9 files changed: 9 ins; 166 del; 19 mod 8365858: FilteredJavaFieldStream is unnecessary Reviewed-by: liach, jsjolen, coleenp, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/27209 From prappo at openjdk.org Tue Sep 16 19:58:02 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 16 Sep 2025 19:58:02 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: <5PSCdIEeoW04LZMgIN3XWQCR0yzsCrAK4G-zttxL0Y8=.659c5863-e2e6-4984-871a-ffffd6858fdb@github.com> On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > An empty commit to kick GHA > /csr A CSR is needed due to the changes to the text that imply a change in semantics, for example, changing 'month" to "day". Even if they are viewed as being incorrect, it needs a thorough review. Thanks for your review, Roger. I'm genuinely confused as to why you think CSR is required here. That month/day is clearly a typo. If it was not, clients would have noticed it long ago. I could imagine that CSR is required for my change to "positive, negative *or zero* length" duration. If so, let me exclude it from this PR, and instead introduce a new PR where we deal with this and other cases of missed zeros systematically. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3300154850 From acobbs at openjdk.org Tue Sep 16 20:06:30 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 16 Sep 2025 20:06:30 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 18:58:41 GMT, Joe Darcy wrote: > Hi @archiecobbs , are there bugs filed to clean the causes of the warnings? Hi @jddarcy, At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :) Here is the list of earlier clean up PR's: * #22906 * #21859 * #21858 * #21857 * #21856 * #21855 * #21854 * #21853 * #21852 * #21851 * #21850 * #21844 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3300177821 From rriggs at openjdk.org Tue Sep 16 20:14:05 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Sep 2025 20:14:05 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > An empty commit to kick GHA Creating a CSR allows the compatible folks take a look for changes and come to their own conclusions. Splitting out changes is fine, but it might be just as efficient to use the PR as is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3300201951 From darcy at openjdk.org Tue Sep 16 20:17:03 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 16 Sep 2025 20:17:03 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 20:03:45 GMT, Archie Cobbs wrote: >> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings? > >> Hi @archiecobbs , are there bugs filed to clean the causes of the warnings? > > Hi @jddarcy, > > At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :) > > Here is the list of earlier clean up PR's: > > * #22906 > * #21859 > * #21858 > * #21857 > * #21856 > * #21855 > * #21854 > * #21853 > * #21852 > * #21851 > * #21850 > * #21844 > > Hi @archiecobbs , are there bugs filed to clean the causes of the warnings? > > Hi @jddarcy, > > At the beginning of this project as a preliminary step I filed a bunch of bugs+PR's to remove unnecessary `@SuppressWarnings` annotations. These were accepted, but they affected every area of the JDK and people kept adding new ones so it was impractical to keep up. The only way to make this cleanup operation "stick" is to fail the build whenever anyone violates it, and of course that requires that this PR be integrated first. If/when that happens I plan to do one final "mop up" round that should finally stick :) > > Here is the list of earlier clean up PR's: > > * [8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) #22906](https://github.com/openjdk/jdk/pull/22906) > > * [8343486: Remove unnecessary @SuppressWarnings annotations and -Xlint:-foo options #21859](https://github.com/openjdk/jdk/pull/21859) > > * [8343484: Remove unnecessary @SuppressWarnings annotations (nio) #21858](https://github.com/openjdk/jdk/pull/21858) > > * [8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) #21857](https://github.com/openjdk/jdk/pull/21857) > > * [8343482: Remove unnecessary @SuppressWarnings annotations (net) #21856](https://github.com/openjdk/jdk/pull/21856) > > * [8343481: Remove unnecessary @SuppressWarnings annotations (kulla) #21855](https://github.com/openjdk/jdk/pull/21855) > > * [8343480: Remove unnecessary @SuppressWarnings annotations (javadoc) #21854](https://github.com/openjdk/jdk/pull/21854) > > * [8343479: Remove unnecessary @SuppressWarnings annotations (hotspot) #21853](https://github.com/openjdk/jdk/pull/21853) > > * [8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) #21852](https://github.com/openjdk/jdk/pull/21852) > > * [8343477: Remove unnecessary @SuppressWarnings annotations (compiler) #21851](https://github.com/openjdk/jdk/pull/21851) > > * [8343476: Remove unnecessary @SuppressWarnings annotations (client) #21850](https://github.com/openjdk/jdk/pull/21850) > > * [8343467: Remove unnecessary @SuppressWarnings annotations (security) #21844](https://github.com/openjdk/jdk/pull/21844) Sounds good; I linked the umbrella issue for the earlier round of cleanup to this issue in JBS. My interest is getting back to at least a subset of modules, including java.base, compiling under "-Xlint:all -Werror" and it sounds like that is the plan as follow-up work after this PR goes in; thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3300210592 From darcy at openjdk.org Tue Sep 16 20:43:06 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 16 Sep 2025 20:43:06 GMT Subject: RFR: 8367787: Expand use of representation equivalence terminology in Float16 Message-ID: Analogous to recent updates made in Float and Double, along with a double -> Float16 typo fix. ------------- Commit messages: - JDK-8367787: Expand use of representation equivalence terminology in Float16 Changes: https://git.openjdk.org/jdk/pull/27322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27322&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367787 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27322/head:pull/27322 PR: https://git.openjdk.org/jdk/pull/27322 From prappo at openjdk.org Tue Sep 16 20:47:34 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 16 Sep 2025 20:47:34 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > An empty commit to kick GHA Thanks for your review, Naoto. > Looks good. > > > I might be missing something, but what does IEEE 754 have to do with this? > > I was simply mentioning there are cases where zeros are signed. Agree that adding zero here is clearer. In regard to directionality, Duration has these three methods: * isPositive, * isNegative, * isZero The spec of the former two makes it very clear, that if `d.isPositive() || d.isNegative()` then `!d.isZero()`. So, if duration of zero length is an acceptable method argument, then we need to add "zero" to "positive or negative" explicitly. The other cases of "positive or negative" that I mentioned relate to _components_ of Duration. These components are primitive int and long. And unless you define a positive int or long value such that its sign bit is 0, then this, for example, should not feel right /** * @serial The number of nanoseconds in the duration, expressed as a fraction of the * number of seconds. This is always positive, and never exceeds 999,999,999. */ private final int nanos; Because I know for a fact that `nanos` can be 0. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3300298919 From rriggs at openjdk.org Tue Sep 16 21:09:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Sep 2025 21:09:52 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > An empty commit to kick GHA src/java.base/share/classes/java/time/Duration.java line 480: > 478: *

> 479: * The result of this method can be a negative duration if the end is before the start. > 480: * To guarantee a positive or zero duration call {@link #abs()} on the result. A bit of a quibble here. Checking the spec of the `isPositive()` method, it does not include zero. If the you intend the "positive" to be the same as the result of the `isPositive` method then I think its best to omit the "zero". The `abs` method would not change anything to be a zero. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27296#discussion_r2353654990 From bpb at openjdk.org Tue Sep 16 21:19:44 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Sep 2025 21:19:44 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format Message-ID: `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path. ------------- Commit messages: - 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format Changes: https://git.openjdk.org/jdk/pull/27324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355342 Stats: 114 lines in 3 files changed: 112 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324 PR: https://git.openjdk.org/jdk/pull/27324 From prappo at openjdk.org Tue Sep 16 21:58:27 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 16 Sep 2025 21:58:27 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: On Tue, 16 Sep 2025 21:06:58 GMT, Roger Riggs wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> An empty commit to kick GHA > > src/java.base/share/classes/java/time/Duration.java line 480: > >> 478: *

>> 479: * The result of this method can be a negative duration if the end is before the start. >> 480: * To guarantee a positive or zero duration call {@link #abs()} on the result. > > A bit of a quibble here. Checking the spec of the `isPositive()` method, it does not include zero. > If the you intend the "positive" to be the same as the result of the `isPositive` method then I think its best to omit the "zero". The `abs` method would not change anything to be a zero. I don't understand. Let's consider an example: jshell> import java.time.* jshell> var i = Instant.now(); i ==> 2025-09-16T21:44:06.464393Z jshell> Duration.between(i, i).abs().isPositive() $3 ==> false So, `abs()` does not translate any duration into positive duration. There exists duration `d` such that `!d.abs().isPositive()`. Any duration for which `d.equals(Duration.ZERO)` is like that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27296#discussion_r2353743450 From bpb at openjdk.org Tue Sep 16 22:03:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Sep 2025 22:03:54 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v2] In-Reply-To: References: Message-ID: <3N8jm71wl95ktiDuCgD3R0ZckhXzadqk8HnHaCzsc4k=.2b07f671-d3ef-4d89-b5f7-633397841324@github.com> > `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8355342: Fix possible sneaky NullPointerException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27324/files - new: https://git.openjdk.org/jdk/pull/27324/files/a3a7c10e..8e93980c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324 PR: https://git.openjdk.org/jdk/pull/27324 From fandreuzzi at openjdk.org Tue Sep 16 22:04:48 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 22:04:48 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v2] In-Reply-To: <3N8jm71wl95ktiDuCgD3R0ZckhXzadqk8HnHaCzsc4k=.2b07f671-d3ef-4d89-b5f7-633397841324@github.com> References: <3N8jm71wl95ktiDuCgD3R0ZckhXzadqk8HnHaCzsc4k=.2b07f671-d3ef-4d89-b5f7-633397841324@github.com> Message-ID: On Tue, 16 Sep 2025 22:03:54 GMT, Brian Burkhalter wrote: >> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355342: Fix possible sneaky NullPointerException src/java.base/windows/classes/java/io/WinNTFileSystem.java line 463: > 461: } > 462: > 463: private static final long HKEY_CURRENT_USER =0x80000001L; Suggestion: private static final long HKEY_CURRENT_USER = 0x80000001L; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2353753718 From bpb at openjdk.org Tue Sep 16 22:11:32 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Sep 2025 22:11:32 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v3] In-Reply-To: References: Message-ID: > `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8355342: Add missing space in constant declaration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27324/files - new: https://git.openjdk.org/jdk/pull/27324/files/8e93980c..833ec725 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324 PR: https://git.openjdk.org/jdk/pull/27324 From bpb at openjdk.org Tue Sep 16 22:11:34 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Sep 2025 22:11:34 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v2] In-Reply-To: References: <3N8jm71wl95ktiDuCgD3R0ZckhXzadqk8HnHaCzsc4k=.2b07f671-d3ef-4d89-b5f7-633397841324@github.com> Message-ID: <-guD6utFzWHW3U2Tj-CuclU6KNVXE5-mloMLkP5KduY=.8d4680d7-5b7d-4a1e-bf51-b0381f8afbaf@github.com> On Tue, 16 Sep 2025 22:02:34 GMT, Francesco Andreuzzi wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8355342: Fix possible sneaky NullPointerException > > src/java.base/windows/classes/java/io/WinNTFileSystem.java line 463: > >> 461: } >> 462: >> 463: private static final long HKEY_CURRENT_USER =0x80000001L; > > Suggestion: > > private static final long HKEY_CURRENT_USER = 0x80000001L; Thanks. Fixed in 833ec72. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27324#discussion_r2353762137 From darcy at openjdk.org Tue Sep 16 23:17:10 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 16 Sep 2025 23:17:10 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: <_GyFprI68yEvF4sr22xSW-JMBxdH3Ed74lwo8cH3kAA=.17a57e7d-a700-4d1a-9877-0f942345c0aa@github.com> On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > An empty commit to kick GHA Okay -- while some of the changes here are clearly bugs, that doesn't obviate the need for a quick CSR review. Regarding _integer_ values, 0 is conventionally neither positive nor negative; it stands alone, hence Math.signum(int): "Returns the signum function of the specified int value. (The return value is -1 if the specified value is negative; 0 if the specified value is zero; and 1 if the specified value is positive.)" Therefore, "non-negative" integers include zero while "positive" integers do not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3300632544 From bpb at openjdk.org Wed Sep 17 00:32:37 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Sep 2025 00:32:37 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4] In-Reply-To: References: Message-ID: > `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8355342: Corrected a comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27324/files - new: https://git.openjdk.org/jdk/pull/27324/files/833ec725..0f29a4f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27324&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27324/head:pull/27324 PR: https://git.openjdk.org/jdk/pull/27324 From dholmes at openjdk.org Wed Sep 17 00:58:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 00:58:38 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> References: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> Message-ID: On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 I'm happy to see this go in now. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3300816267 From shaojin.wensj at alibaba-inc.com Wed Sep 17 01:13:24 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Wed, 17 Sep 2025 09:13:24 +0800 Subject: =?UTF-8?B?UHJvcG9zYWwgdG8gcmVtb3ZlIFN0cmluZ0NvbmNhdEZhY3RvcnkjZ2VuZXJhdGVNSElubGlu?= =?UTF-8?B?ZUNvcHk=?= Message-ID: With the introduction of 8338930: StringConcatFactory hardCoded string concatenation strategy, the StringConcatFactory#generateMHInlineCopy method is no longer used by default. ```java public final class StringConcatFactory { private static final int HIGH_ARITY_THRESHOLD; static { String highArity = VM.getSavedProperty("java.lang.invoke.StringConcat.highArityThreshold"); HIGH_ARITY_THRESHOLD = highArity != null ? Integer.parseInt(highArity) : 0; } public static CallSite makeConcatWithConstants(MethodHandles.Lookup lookup, String name, MethodType concatType, String recipe, Object... constants) throws StringConcatException { MethodHandle mh = makeSimpleConcat(concatType, constantStrings); if (mh == null && concatType.parameterCount() <= HIGH_ARITY_THRESHOLD) { mh = generateMHInlineCopy(concatType, constantStrings); // no longer used by default. } } } ``` After a year of community use, the InlineHiddenClassStrategy has proven to work well, so I recommend removing the implementation of StringConcatFactory#generateMHInlineCopy. - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From cstein at openjdk.org Wed Sep 17 05:41:55 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 17 Sep 2025 05:41:55 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Update to use correct library directories See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files - 8361950: Set required version to 8+2 - 8361950: Update to use jtreg 8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26261/files - new: https://git.openjdk.org/jdk/pull/26261/files/12b0d0f5..7f2017b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=03-04 Stats: 34669 lines in 1054 files changed: 16580 ins; 9869 del; 8220 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From alanb at openjdk.org Wed Sep 17 06:41:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 06:41:54 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 make/autoconf/lib-tests.m4 line 31: > 29: > 30: # Minimum supported versions > 31: JTREG_MINIMUM_VERSION=8 Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354467094 From cstein at openjdk.org Wed Sep 17 06:45:37 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 17 Sep 2025 06:45:37 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 06:39:17 GMT, Alan Bateman wrote: >> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 >> - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 >> - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 >> - Update to use correct library directories >> >> See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files >> - 8361950: Set required version to 8+2 >> - 8361950: Update to use jtreg 8 > > make/autoconf/lib-tests.m4 line 31: > >> 29: >> 30: # Minimum supported versions >> 31: JTREG_MINIMUM_VERSION=8 > > Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious). It's 8. The +2 refers to the build number, which is required in other places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354476356 From alanb at openjdk.org Wed Sep 17 06:52:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 06:52:34 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: <166qfREU1L7ZkPFg-uAVlnjoiaysBbGxYRRfAGU147E=.ba03b95e-726e-4e31-b05e-e0a2afebcfd6@github.com> On Wed, 17 Sep 2025 06:43:20 GMT, Christian Stein wrote: >> make/autoconf/lib-tests.m4 line 31: >> >>> 29: >>> 30: # Minimum supported versions >>> 31: JTREG_MINIMUM_VERSION=8 >> >> Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious). > > It's 8. The +2 refers to the build number, which is required in other places. Thanks for clarifying. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354488946 From epeter at openjdk.org Wed Sep 17 07:02:43 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 17 Sep 2025 07:02:43 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v13] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:43:11 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request incrementally with one additional commit since the last revision: > > Add an IR rule for vector mask cast operation @erifan Thanks for the work! All tests pass on my side, patch looks good to me too :) ------------- Marked as reviewed by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24674#pullrequestreview-3232943779 From duke at openjdk.org Wed Sep 17 07:26:52 2025 From: duke at openjdk.org (erifan) Date: Wed, 17 Sep 2025 07:26:52 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v13] In-Reply-To: References: Message-ID: <27SoQ3ZhkmDXmpLXeRiBu3eJychQuq-BgZ9VEE5Ab_U=.82d70745-599b-4edf-ba8e-54c4956ea166@github.com> On Mon, 15 Sep 2025 05:43:11 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request incrementally with one additional commit since the last revision: > > Add an IR rule for vector mask cast operation Thanks all for your help, I'll integrate the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-3301646116 From duke at openjdk.org Wed Sep 17 07:26:53 2025 From: duke at openjdk.org (duke) Date: Wed, 17 Sep 2025 07:26:53 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v13] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 05:43:11 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request incrementally with one additional commit since the last revision: > > Add an IR rule for vector mask cast operation @erifan Your change (at version 56bb34ffe3ca104c8f838a41f33b1d90bb10b68b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-3301651892 From duke at openjdk.org Wed Sep 17 07:35:04 2025 From: duke at openjdk.org (erifan) Date: Wed, 17 Sep 2025 07:35:04 GMT Subject: Integrated: 8354242: VectorAPI: combine vector not operation with compare In-Reply-To: References: Message-ID: <9jXNL4s-eyJLY6-tYH6-4B5AFrZi-Kr_-J-S2H88Lmc=.8fe08e80-6ed1-4971-b23a-9e1a5b8a4916@github.com> On Wed, 16 Apr 2025 06:39:33 GMT, erifan wrote: > This patch optimizes the following patterns: > For integer types: > > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. > > For float and double types: > > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: > > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 > testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 > testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 > testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 > testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 > testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 > testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 > testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 > testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 > testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 > testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 > testCompareLTMaskNotLong ops/s 856502.26... This pull request has now been integrated. Changeset: 45cc515f Author: erifan Committer: Xiaohong Gong URL: https://git.openjdk.org/jdk/commit/45cc515f451accfd1a0a36d17ccb38d428a5d035 Stats: 1635 lines in 7 files changed: 1634 ins; 0 del; 1 mod 8354242: VectorAPI: combine vector not operation with compare Reviewed-by: epeter, jbhateja, xgong ------------- PR: https://git.openjdk.org/jdk/pull/24674 From ihse at openjdk.org Wed Sep 17 08:41:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 08:41:57 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3233332473 From ihse at openjdk.org Wed Sep 17 08:51:28 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 08:51:28 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 17:14:36 GMT, Roger Riggs wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove debug code > > src/java.base/windows/native/launcher/relauncher.c line 79: > >> 77: backslashes = 0; >> 78: } else { >> 79: // Backslashes not preceeding a quote is copied without escaping > > is -> are Thanks. This is my eternal nemesis in English. Why can't you just be like normal people and use the same word independent on numerus?! ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2354790932 From alanb at openjdk.org Wed Sep 17 09:38:02 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 09:38:02 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 00:32:37 GMT, Brian Burkhalter wrote: >> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355342: Corrected a comment Would it be possible to provide a summary as to why we don't run into this with toRealPath? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3302150712 From adinn at openjdk.org Wed Sep 17 09:47:10 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 17 Sep 2025 09:47:10 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:40:48 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added logging about @AOTSafeClassInitializer classes that have not been initialized Thanks for the additions.Looks good! ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27024#pullrequestreview-3233581981 From prappo at openjdk.org Wed Sep 17 10:31:45 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 17 Sep 2025 10:31:45 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <_GyFprI68yEvF4sr22xSW-JMBxdH3Ed74lwo8cH3kAA=.17a57e7d-a700-4d1a-9877-0f942345c0aa@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> <_GyFprI68yEvF4sr22xSW-JMBxdH3Ed74lwo8cH3kAA=.17a57e7d-a700-4d1a-9877-0f942345c0aa@github.com> Message-ID: On Tue, 16 Sep 2025 23:14:13 GMT, Joe Darcy wrote: > Okay -- while some of the changes here are clearly bugs, that doesn't obviate the need for a quick CSR review. I see. > Regarding _integer_ values, 0 is conventionally neither positive nor negative; it stands alone, hence Math.signum(int): > > "Returns the signum function of the specified int value. (The return value is -1 if the specified value is negative; 0 if the specified value is zero; and 1 if the specified value is positive.)" > While JLS as well as `Long` and `Integer` primitive wrapper classes do not seem to define what positive and negative integers are, other core classes hint on these terms strongly. One example is `Math.signum`, which you provided. Another example is `Comparator.compare(T, T)`: > Compares its two arguments for order. Returns a negative integer, zero, or a positive integer as the first argument is less than, equal to, or greater than the second. So yes, in Java, an integer i is called: * positive, if i > 0 * negative, if i < 0 * zero, if i = 0 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3302355429 From prappo at openjdk.org Wed Sep 17 11:50:54 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 17 Sep 2025 11:50:54 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: On Tue, 16 Sep 2025 17:10:18 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > An empty commit to kick GHA @jodastephen, could you comment on any of the questions in the PR summary? Also, I don't use Period often, but I find this method perplexing. How is it supposed to be used? /** * Checks if any of the three units of this period are negative. *

* This checks whether the years, months or days units are less than zero. * * @return true if any unit of this period is negative */ public boolean isNegative() ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3302620443 From liach at openjdk.org Wed Sep 17 11:51:58 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Sep 2025 11:51:58 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3234055339 From ghan at openjdk.org Wed Sep 17 12:14:37 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Wed, 17 Sep 2025 12:14:37 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:32:13 GMT, Guanqiang Han wrote: > Please review this patch. > > **Description:** > > Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. > > **Test:** > > GHA Hi @RogerRiggs @liach , Could you kindly take a look at this PR when you have time? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27285#issuecomment-3302702353 From duke at openjdk.org Wed Sep 17 12:21:45 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 17 Sep 2025 12:21:45 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v14] In-Reply-To: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: > A formula to lower the overestimate for the precision of an exact quotient, without introducing too expensive operations of division on numerator and denominator. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Small optimizations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27271/files - new: https://git.openjdk.org/jdk/pull/27271/files/77dfc536..f92eb296 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27271&range=12-13 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 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 From ayang at openjdk.org Wed Sep 17 12:55:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 12:55:53 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3234308768 From syan at openjdk.org Wed Sep 17 13:00:53 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 17 Sep 2025 13:00:53 GMT Subject: RFR: 8367869: Test java/io/FileDescriptor/Sync.java timed out Message-ID: <3xrsCUmi-ECmg8gMmBjCKpTBLnNnWLocsPP44Yh4ymI=.dccbe40f-6c53-43ac-8be1-42f2f82834e8@github.com> Hi all, After [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555) changed the default TIMEOUT_FACTOR from 4 to 1, test java/io/FileDescriptor/Sync.java intermittent timed out when run with other test simultancely. If I run this test seperately, it shows that test exhaust about 40+ seconds to finish on linux-x64 machine with release jdk build. This PR change the test count from 10_000 to 1_000, this will make test exhaust less time to finish. I think 1_000 will be enough. ------------- Commit messages: - 8367869: Test java/io/FileDescriptor/Sync.java timed out Changes: https://git.openjdk.org/jdk/pull/27344/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27344&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367869 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27344.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27344/head:pull/27344 PR: https://git.openjdk.org/jdk/pull/27344 From rriggs at openjdk.org Wed Sep 17 13:34:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 13:34:53 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:32:13 GMT, Guanqiang Han wrote: > Please review this patch. > > **Description:** > > Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. > > **Test:** > > GHA Can you add a test of the maximum length UTF-8 encoded string. That would be a string of Integer.MAX_VALUE/2 characters that were > 0xff. It will likely have to write it to a file and read it back, ByteArrayIn/OutStream wouldn't be big enough. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27285#issuecomment-3303034163 From rriggs at openjdk.org Wed Sep 17 13:45:48 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 13:45:48 GMT Subject: RFR: 8367031: Revert "8334742: Change java.time month/day field types to 'byte'" Message-ID: This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. Restore the previous field types to maintain compatibility with previous releases of the serialized form of classes of java.time. The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. ------------- Commit messages: - Revert "8334742: Change java.time month/day field types to 'byte'" Changes: https://git.openjdk.org/jdk/pull/27346/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27346&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367031 Stats: 17 lines in 4 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27346/head:pull/27346 PR: https://git.openjdk.org/jdk/pull/27346 From mbaesken at openjdk.org Wed Sep 17 13:46:44 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 Sep 2025 13:46:44 GMT Subject: RFR: 8367573: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_aix.c In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 13:30:40 GMT, Matthias Baesken wrote: > Similar to JDK-8367138 , we should add a JNI exception check to os_getCmdlineAndUserInfo on AIX . Hi Roger , thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27313#issuecomment-3303080280 From mbaesken at openjdk.org Wed Sep 17 13:50:05 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 Sep 2025 13:50:05 GMT Subject: Integrated: 8367573: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_aix.c In-Reply-To: References: Message-ID: <9JfEQX8PvNN48iMCbNDdnvTxqOBc6wSJVzgG8asBZwc=.1e5fc57a-e7c1-493b-8a8e-38aab7b796f9@github.com> On Tue, 16 Sep 2025 13:30:40 GMT, Matthias Baesken wrote: > Similar to JDK-8367138 , we should add a JNI exception check to os_getCmdlineAndUserInfo on AIX . This pull request has now been integrated. Changeset: 1ba84141 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/1ba841410bf4af0377a7192717d4ebc5d6d9f3f9 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8367573: JNI exception pending in os_getCmdlineAndUserInfo of ProcessHandleImpl_aix.c Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/27313 From alanb at openjdk.org Wed Sep 17 13:54:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 13:54:38 GMT Subject: RFR: 8367031: Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Looks okay, and good for 25u too. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27346#pullrequestreview-3234583232 From rriggs at openjdk.org Wed Sep 17 13:54:40 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 13:54:40 GMT Subject: RFR: 8367031: Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: <8QbtnS3GFDphvVq2UOi3flZvNMz0ddm11wEvM3ItqkM=.affee8d9-46ac-47a7-bdcd-2715258e3536@github.com> On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. fyi, this will be backported to JDK 25 in a future update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303106389 From liach at openjdk.org Wed Sep 17 13:58:23 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Sep 2025 13:58:23 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:32:13 GMT, Guanqiang Han wrote: > Please review this patch. > > **Description:** > > Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. > > **Test:** > > GHA Do you think we should use `> 65535L` or `ExactConversionsSupport.isLongToCharExact`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27285#issuecomment-3303123698 From rotanolexandr842 at gmail.com Wed Sep 17 13:58:28 2025 From: rotanolexandr842 at gmail.com (Olexandr Rotan) Date: Wed, 17 Sep 2025 16:58:28 +0300 Subject: Stream.concat with varagrs Message-ID: Greetings to everyone on the list. When working on some routine tasks recently, I have encountered a, seemingly to me, strange decision in design of Stream.concat method, specifically the fact that it accepts exactly two streams. My concrete example was something along the lines of var studentIds = ...; var teacherIds = ...; var partnerIds = ...; return Stream.concat( studentIds.stream(), teacherIds.stream(), partnerIds.stream() // oops, this one doesn't work ) so I had to transform concat to a rather ugly Stream.concat( studentIds.stream(), Stream.concat( teacherIds.stream(), partnerIds.stream() ) ) Later on I had to add 4th stream of a single element (Stream.of), and this one became even more ugly When I first wrote third argument to concat and saw that IDE highlights it as error, I was very surprised. This design seems inconsistent not only with the whole java stdlib, but even with Stream.of static method of the same class. Is there any particular reason why concat takes exactly to arguments? I would say that, even if just in a form of sugar method that just does reduce on array (varagrs) of streams, this would be a great quality of life improvement, but I'm sure there also may be some room for performance improvement. Of course, there are workarounds like Stream.of + flatmap, but: 1. It gets messy when trying to concat streams of literal elements set (Stream.of) and streams of collections or arrays 2. It certainly has significant performance overhead 3. It still doesn't explain absence of varagrs overload of concat So, once again, is there any particular reason to restrict arguments list to exactly two streams? If not, I would be happy to contribute Stream.concat(Stream... streams) overload. Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Wed Sep 17 13:59:20 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Sep 2025 13:59:20 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v3] In-Reply-To: References: Message-ID: <2Ltx_pzlbX-gIq0iV-vTzIxVcDm6LwxxhxQw5XPxFWc=.85855e71-f1a9-45f9-98d2-c46301e1916a@github.com> > Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: - Rework the test to skip in the restricted environment - Simplify Win8365790Test.ps1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27264/files - new: https://git.openjdk.org/jdk/pull/27264/files/df6d8318..7a597c68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=01-02 Stats: 149 lines in 5 files changed: 94 ins; 20 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/27264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27264/head:pull/27264 PR: https://git.openjdk.org/jdk/pull/27264 From shade at openjdk.org Wed Sep 17 14:00:48 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Sep 2025 14:00:48 GMT Subject: RFR: 8367031: Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Is this a straight backout of https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624? Shouldn't this be `[BACKOUT] ...` issue then? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303133711 From liach at openjdk.org Wed Sep 17 14:00:46 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Sep 2025 14:00:46 GMT Subject: RFR: 8367031: Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: <1jixFPEY5_GPPCiZ7BqFpgen2mgfxDtxviIp0yEzAJ8=.73574e25-7a08-4d75-b70b-d63fb51b8a0c@github.com> On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27346#pullrequestreview-3234610609 From rriggs at openjdk.org Wed Sep 17 14:00:49 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 14:00:49 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: On Tue, 16 Sep 2025 21:55:36 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/time/Duration.java line 480: >> >>> 478: *

>>> 479: * The result of this method can be a negative duration if the end is before the start. >>> 480: * To guarantee a positive or zero duration call {@link #abs()} on the result. >> >> A bit of a quibble here. Checking the spec of the `isPositive()` method, it does not include zero. >> If the you intend the "positive" to be the same as the result of the `isPositive` method then I think its best to omit the "zero". The `abs` method would not change anything to be a zero. > > I don't understand. Let's consider an example: > > jshell> import java.time.* > > jshell> var i = Instant.now(); > i ==> 2025-09-16T21:44:06.464393Z > > jshell> Duration.between(i, i).abs().isPositive() > $3 ==> false > > So, `abs()` does not translate any duration into positive duration. There exists duration `d` such that `!d.abs().isPositive()`. Any duration for which `d.equals(Duration.ZERO)` is like that. Joe's suggestion of "non-negative" (instead of positive) is probably the best replacement. Mentioning using `abs()` with a zero argument didn't parse well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27296#discussion_r2355624787 From asemenyuk at openjdk.org Wed Sep 17 14:02:06 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Sep 2025 14:02:06 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:02:45 GMT, Alexey Semenyuk wrote: >> Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. > > Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: > > - Hide powershell console > - Add extra assert Reworked the test to work (skip) in the environment where `GenerateConsoleCtrlEvent()` function called from the PowerShell script doesn't go through to a child process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27264#issuecomment-3303140521 From asemenyuk at openjdk.org Wed Sep 17 14:02:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Sep 2025 14:02:08 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v2] In-Reply-To: References: Message-ID: On Sat, 13 Sep 2025 01:16:49 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: >> >> - Hide powershell console >> - Add extra assert > > Looks good. I assume parent process will terminate as well after child process? @sashamatveev please review again ------------- PR Comment: https://git.openjdk.org/jdk/pull/27264#issuecomment-3303142527 From alanb at openjdk.org Wed Sep 17 14:11:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 14:11:57 GMT Subject: RFR: 8367031: Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: <1YNjpvxLs-mU4zSsMA3JvHIkn8GwxKzX258HxnUznsY=.7bbb9995-04c5-4442-9412-3a9b35c66c19@github.com> On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Are you planning to add tests to catch this sort of issue, even if only for the classes in java.time for now, or are you thinking about a follow-up issue? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303186007 From viktor.klang at oracle.com Wed Sep 17 14:14:08 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Wed, 17 Sep 2025 14:14:08 +0000 Subject: Stream.concat with varagrs In-Reply-To: References: Message-ID: Hi Olexandr, Great question! I guess a "simple" implementation of an N-ary concat could work, but it would have performance implications (think a recursive use of Stream.concat()) but if you look at the implementation of Stream.concat's backing Spliterator, you'll see how complex it would be to implement it in a truly N-ary way (a challenging exercise for the reader?): https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Streams.java#L690 Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev on behalf of Olexandr Rotan Sent: Wednesday, 17 September 2025 15:58 To: core-libs-dev Subject: Stream.concat with varagrs Greetings to everyone on the list. When working on some routine tasks recently, I have encountered a, seemingly to me, strange decision in design of Stream.concat method, specifically the fact that it accepts exactly two streams. My concrete example was something along the lines of var studentIds = ...; var teacherIds = ...; var partnerIds = ...; return Stream.concat( studentIds.stream(), teacherIds.stream(), partnerIds.stream() // oops, this one doesn't work ) so I had to transform concat to a rather ugly Stream.concat( studentIds.stream(), Stream.concat( teacherIds.stream(), partnerIds.stream() ) ) Later on I had to add 4th stream of a single element (Stream.of), and this one became even more ugly When I first wrote third argument to concat and saw that IDE highlights it as error, I was very surprised. This design seems inconsistent not only with the whole java stdlib, but even with Stream.of static method of the same class. Is there any particular reason why concat takes exactly to arguments? I would say that, even if just in a form of sugar method that just does reduce on array (varagrs) of streams, this would be a great quality of life improvement, but I'm sure there also may be some room for performance improvement. Of course, there are workarounds like Stream.of + flatmap, but: 1. It gets messy when trying to concat streams of literal elements set (Stream.of) and streams of collections or arrays 2. It certainly has significant performance overhead 3. It still doesn't explain absence of varagrs overload of concat So, once again, is there any particular reason to restrict arguments list to exactly two streams? If not, I would be happy to contribute Stream.concat(Stream... streams) overload. Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at gmail.com Wed Sep 17 14:15:01 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 17 Sep 2025 15:15:01 +0100 Subject: Stream.concat with varagrs In-Reply-To: References: Message-ID: > this would be a great quality of life improvement Is it such a useful use case, though? I mean, it's no different from SequenceInputStream(...) or Math.min/max for that matter. I very rarely have to do Math.min(a, Math(min(b, c)) or some such. And those methods predate streams API by more than a decade. Separately, it's not just one method. Consider that `concat` is also implemented in specialized streams such as IntStream, DoubleStream, and LongStream. On Wed, Sep 17, 2025 at 2:58?PM Olexandr Rotan wrote: > > Greetings to everyone on the list. > > When working on some routine tasks recently, I have encountered a, seemingly to me, strange decision in design of Stream.concat method, specifically the fact that it accepts exactly two streams. My concrete example was something along the lines of > > var studentIds = ...; > var teacherIds = ...; > var partnerIds = ...; > > return Stream.concat( > studentIds.stream(), > teacherIds.stream(), > partnerIds.stream() // oops, this one doesn't work > ) > > so I had to transform concat to a rather ugly > Stream.concat( > studentIds.stream(), > Stream.concat( > teacherIds.stream(), > partnerIds.stream() > ) > ) > > Later on I had to add 4th stream of a single element (Stream.of), and this one became even more ugly > > When I first wrote third argument to concat and saw that IDE highlights it as error, I was very surprised. This design seems inconsistent not only with the whole java stdlib, but even with Stream.of static method of the same class. Is there any particular reason why concat takes exactly to arguments? > > I would say that, even if just in a form of sugar method that just does reduce on array (varagrs) of streams, this would be a great quality of life improvement, but I'm sure there also may be some room for performance improvement. > > Of course, there are workarounds like Stream.of + flatmap, but: > > 1. It gets messy when trying to concat streams of literal elements set (Stream.of) and streams of collections or arrays > 2. It certainly has significant performance overhead > 3. It still doesn't explain absence of varagrs overload of concat > > So, once again, is there any particular reason to restrict arguments list to exactly two streams? If not, I would be happy to contribute Stream.concat(Stream... streams) overload. > > Best regards > > > From dmlloyd at openjdk.org Wed Sep 17 14:11:58 2025 From: dmlloyd at openjdk.org (David Lloyd) Date: Wed, 17 Sep 2025 14:11:58 GMT Subject: RFR: 8367031: Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: <1bW5XQSCD4DRwvJQjEwoIN714PbydfyWwN8beACdqk0=.5ab255ab-56d6-427d-b0b1-88321e3976ee@github.com> On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Would it not have been sufficient to add a `serialPersistentFields` which defines the fields as their "old" types? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303186083 From duke at openjdk.org Wed Sep 17 14:31:05 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 17 Sep 2025 14:31:05 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v10] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 13:01:34 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Update tests. Thanks for the review(s). The internal CI tests pass 1-3, so integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27203#issuecomment-3303277314 From duke at openjdk.org Wed Sep 17 14:31:06 2025 From: duke at openjdk.org (duke) Date: Wed, 17 Sep 2025 14:31:06 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v10] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 13:01:34 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Update tests. @david-beaumont Your change (at version 49cc2a3cb8f46a9b4d1d2b61d99601ca7c3a6736) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27203#issuecomment-3303284296 From prappo at openjdk.org Wed Sep 17 14:40:06 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 17 Sep 2025 14:40:06 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> Message-ID: <7WMh5xltSUpVuHS4EGIFpy_3arOI1BygQIU7LmKH6fk=.5ac991bb-4e2f-4ef0-aa4e-29eb1be0e9fa@github.com> On Wed, 17 Sep 2025 13:58:03 GMT, Roger Riggs wrote: >> I don't understand. Let's consider an example: >> >> jshell> import java.time.* >> >> jshell> var i = Instant.now(); >> i ==> 2025-09-16T21:44:06.464393Z >> >> jshell> Duration.between(i, i).abs().isPositive() >> $3 ==> false >> >> So, `abs()` does not translate any duration into positive duration. There exists duration `d` such that `!d.abs().isPositive()`. Any duration for which `d.equals(Duration.ZERO)` is like that. > > Joe's suggestion of "non-negative" (instead of positive) is probably the best replacement. > > Mentioning using `abs()` with a zero argument didn't parse well. Okay, but don't we need some verbiage -- however little -- on what "non-negative" means for Duration, or we consider it self-evident? (Genuine question.) Can we also tie this change with "positive or negative" for primitive components? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27296#discussion_r2355757830 From rriggs at openjdk.org Wed Sep 17 14:41:14 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 14:41:14 GMT Subject: RFR: 8367031: Regression in serialization of LocalDate class objects In-Reply-To: <1YNjpvxLs-mU4zSsMA3JvHIkn8GwxKzX258HxnUznsY=.7bbb9995-04c5-4442-9412-3a9b35c66c19@github.com> References: <1YNjpvxLs-mU4zSsMA3JvHIkn8GwxKzX258HxnUznsY=.7bbb9995-04c5-4442-9412-3a9b35c66c19@github.com> Message-ID: On Wed, 17 Sep 2025 14:08:51 GMT, Alan Bateman wrote: > Are you planning to add tests to catch this sort of issue, even if only for the classes in java.time for now, or are you thinking about a follow-up issue? I'm working on a new test to serialize classes to an archive and compare the archived serialized classes against the current runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303317384 From rriggs at openjdk.org Wed Sep 17 14:41:16 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 14:41:16 GMT Subject: RFR: 8367031: Regression in serialization of LocalDate class objects In-Reply-To: <1bW5XQSCD4DRwvJQjEwoIN714PbydfyWwN8beACdqk0=.5ab255ab-56d6-427d-b0b1-88321e3976ee@github.com> References: <1bW5XQSCD4DRwvJQjEwoIN714PbydfyWwN8beACdqk0=.5ab255ab-56d6-427d-b0b1-88321e3976ee@github.com> Message-ID: On Wed, 17 Sep 2025 14:08:52 GMT, David Lloyd wrote: > Would it not have been sufficient to add a `serialPersistentFields` which defines the fields as their "old" types? Using serialPersistenFields is an option; but to correct the regression, it was cleaner to just revert/backout the change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303327231 From rriggs at openjdk.org Wed Sep 17 14:43:30 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 14:43:30 GMT Subject: RFR: 8367031: [backout] Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. > Is this a straight backout of [4ced4e7](https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624)? Shouldn't this be `[BACKOUT] ...` issue then? Yes, it is a straight backout; I can add the [backout] prefix to the regression title. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303338257 From liach at openjdk.org Wed Sep 17 14:47:06 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Sep 2025 14:47:06 GMT Subject: RFR: 8367005: ImageReader refactor caused performance regressions for startup and footprint [v10] In-Reply-To: References: Message-ID: <_8KWyHvV_Jughp9vRC8yVtTh_FoFd7LM6SHLzvnlQ1s=.ec1b0273-be2b-4f6e-b422-0305b2821842@github.com> On Tue, 16 Sep 2025 13:01:34 GMT, David Beaumont wrote: >> Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. >> >> Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. >> >> The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. >> >> In particular: >> 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. >> 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. >> >> Thus two new methods are added to resolve these cases: >> * findResourceNode(module, path) >> * containsResource(module, path) >> >> Their API takes module and path separately so as to not be confusable with findNode(nodename). >> >> However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Update tests. Thanks David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27203#issuecomment-3303351527 From daniel.fuchs at oracle.com Wed Sep 17 14:47:03 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Sep 2025 15:47:03 +0100 Subject: Stream.concat with varagrs In-Reply-To: References: Message-ID: Hi, Not immediately obvious but you can create a Stream> using Stream.of and reduce that using Stream::concat to obtain a Stream. Something along those lines: ``` var stream = Stream.of(Stream.of(1,2,3), Stream.of(4), Stream.of(5, 6, 7, 8)).reduce(Stream.empty(), Stream::concat, Stream::concat); stream.forEach(System.out::println); 1 2 3 4 5 6 7 8 ``` No idea what the perf would be :-) cheers, -- daniel On 17/09/2025 15:15, Pavel Rappo wrote: >> this would be a great quality of life improvement > > Is it such a useful use case, though? I mean, it's no different from > SequenceInputStream(...) or Math.min/max for that matter. I very > rarely have to do Math.min(a, Math(min(b, c)) or some such. And those > methods predate streams API by more than a decade. > > Separately, it's not just one method. Consider that `concat` is also > implemented in specialized streams such as IntStream, DoubleStream, > and LongStream. > > On Wed, Sep 17, 2025 at 2:58?PM Olexandr Rotan > wrote: >> >> Greetings to everyone on the list. >> >> When working on some routine tasks recently, I have encountered a, seemingly to me, strange decision in design of Stream.concat method, specifically the fact that it accepts exactly two streams. My concrete example was something along the lines of >> >> var studentIds = ...; >> var teacherIds = ...; >> var partnerIds = ...; >> >> return Stream.concat( >> studentIds.stream(), >> teacherIds.stream(), >> partnerIds.stream() // oops, this one doesn't work >> ) >> >> so I had to transform concat to a rather ugly >> Stream.concat( >> studentIds.stream(), >> Stream.concat( >> teacherIds.stream(), >> partnerIds.stream() >> ) >> ) >> >> Later on I had to add 4th stream of a single element (Stream.of), and this one became even more ugly >> >> When I first wrote third argument to concat and saw that IDE highlights it as error, I was very surprised. This design seems inconsistent not only with the whole java stdlib, but even with Stream.of static method of the same class. Is there any particular reason why concat takes exactly to arguments? >> >> I would say that, even if just in a form of sugar method that just does reduce on array (varagrs) of streams, this would be a great quality of life improvement, but I'm sure there also may be some room for performance improvement. >> >> Of course, there are workarounds like Stream.of + flatmap, but: >> >> 1. It gets messy when trying to concat streams of literal elements set (Stream.of) and streams of collections or arrays >> 2. It certainly has significant performance overhead >> 3. It still doesn't explain absence of varagrs overload of concat >> >> So, once again, is there any particular reason to restrict arguments list to exactly two streams? If not, I would be happy to contribute Stream.concat(Stream... streams) overload. >> >> Best regards >> >> >> From ihse at openjdk.org Wed Sep 17 14:49:00 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 14:49:00 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v10] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24380/files - new: https://git.openjdk.org/jdk/pull/24380/files/e9925dab..5a554a55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From duke at openjdk.org Wed Sep 17 14:49:43 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 17 Sep 2025 14:49:43 GMT Subject: Integrated: 8367005: ImageReader refactor caused performance regressions for startup and footprint In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 21:51:38 GMT, David Beaumont wrote: > Summary: Add two new methods to ImageReader to make SystemModuleReader more performant. > > Analysis of benchmarks shows that when the vast majority of resources (~11,000 in the Perfstartup-SwingSet-G1 benchmark) tested for in SystemModuleReader do NOT exist, performance is degraded compared to this code prior to the refactoring in JDK-8360037. > > The current refactoring of ImageReader has everything going through a single "findNode()" method for simplest possible encapsulation, but while this is functionally correct, it's not tuned for testing for the non-existence of resources. > > In particular: > 1. SystemModuleReader only requests resources (i.e. things in the jimage file with paths *not* starting /modules/ or /packages/). This means findNode() does two look-ups for the resource, the first of which will always fail. > 2. The containsResource() logic doesn't need to create and cache nodes in ImageReader, it can just check for the presence of an ImageLocation corresponding to a resource. > > Thus two new methods are added to resolve these cases: > * findResourceNode(module, path) > * containsResource(module, path) > > Their API takes module and path separately so as to not be confusable with findNode(nodename). > > However care must be taken to prevent these methods being fooled into returning non-resource entries (this was possible before the refactoring by using module names like "modules" or "packages") so new tests have been added. This pull request has now been integrated. Changeset: 9949ee31 Author: David Beaumont Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/9949ee3163a31f6f3c13c4fe34e8c0166210719e Stats: 175 lines in 4 files changed: 153 ins; 13 del; 9 mod 8367005: ImageReader refactor caused performance regressions for startup and footprint Reviewed-by: alanb, rriggs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27203 From asemenyuk at openjdk.org Wed Sep 17 14:53:29 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Sep 2025 14:53:29 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v4] In-Reply-To: References: Message-ID: > Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Fix indent and comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27264/files - new: https://git.openjdk.org/jdk/pull/27264/files/7a597c68..d8ad4975 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27264/head:pull/27264 PR: https://git.openjdk.org/jdk/pull/27264 From ihse at openjdk.org Wed Sep 17 14:54:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 14:54:21 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 17:29:59 GMT, Roger Riggs wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove debug code > > src/java.base/windows/native/launcher/relauncher.c line 153: > >> 151: } >> 152: >> 153: // Our executable name (should not be quoted) > > ok here, because the full path is being explicitly passed to CreateProcess. > If the command line is to be parsed and the executable path contains a space, CreateProcess does say it should be quoted. It would be good to have a test case with a space in the executable path. Indeed, this seems sus. I need to dig more into this. I recall initially quoting all arguments and then running into problems with the executable. Maybe it is that spaces needs to be quoted, but not other special characters. I'll check what you are doing in ProcessImpl.java and see if I can align my code to do the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2355810340 From rotanolexandr842 at gmail.com Wed Sep 17 15:04:33 2025 From: rotanolexandr842 at gmail.com (Olexandr Rotan) Date: Wed, 17 Sep 2025 18:04:33 +0300 Subject: Stream.concat with varagrs In-Reply-To: References: Message-ID: Hello everyone! Thanks for your responses I will start of by answering to Viktor I guess a "simple" implementation of an N-ary concat could work, but it > would have performance implications (think a recursive use of > Stream.concat()) I too find just the addition of small reduction-performing sugar methods rather unsatisfactory and most certainly not bringing enough value to be considered a valuable addition. Moreover, I have not checked it myself, but I would dare to guess that popular utility libraries such as Guava or Apache Commons already provide this sort of functionality in their utility classes. Though, if this method could bring some significant performance benefits, I think it may be a valuable candidate to consider. Though, to me as a user, the main value would be uniformity of the API and ease of use and read. The main reason I am writing about this in the first place is the unintuitive inconsistency with many other static methods-creators that happily accept varargs I may play around with this spliterator code you have linked to to see if I could make it generalized for arrays of streams Now, answering to Pavel Is it such a useful use case, though? I mean, it's no different from > SequenceInputStream(...) or Math.min/max for that matter. I very rarely > have to do Math.min(a, Math(min(b, c)) or some such. I certainly see your point, but I would dare to say that most applications rely on the streams much more than SequenceInputStream and Math classes, and their lookalikes. Stream.concat is primarily a way to merge a few datasource outputs into one, for later uniform processing, which, in the nutshell, is one of the most common tasks in data-centric applications. Of course, not every such use case has characteristics that incline developers to use Stream.concat, such as combination of Stream.of and Collection.stream() sources, and even if they do, not every case that fits previous requirement requires to merge more than 2 sources. However, for mid-to-large scale apps, for which java is known the most, I would say it's fairly common. I went over our codebase and found that there were at least 10+ usages of concat, and a few of them followed this kinda ugly pattern of nested concates. Separately, it's not just one method. Consider that `concat` is also > implemented in specialized streams such as IntStream, DoubleStream, and > LongStream. This is unfortunate, but I would dare to say that once Reference spliterrator is implemented, others may also be derived by analogy fairly quickly And last but not least, answering Daniel Not immediately obvious but you can create a Stream> using > Stream.of and reduce that using Stream::concat to obtain a Stream. Something along those lines: ``` > var stream = Stream.of(Stream.of(1,2,3), Stream.of(4), Stream.of(5, 6, > 7, 8)).reduce(Stream.empty(), Stream::concat, Stream::concat); This is what I meant by "reduction-like" implementation, which is fairly straightforward, but just from the looks of it, one could assume that this solution will surely have performance consequences, even if using flatmap insead of reduce. Not sure though, how often people would want to use such approach on the array of streams huge enough for the performance difference to be noticable, though I would assume that there is a non-linear scale of consumed time and resources from the length of streams array due to the implementation of concat method. Nevertheless, this is an acceptable workaround for such cases, even though not the most readable one. Even if this approach is accepted as sufficient for such cases of n-sized array of streams merging, It would probably make some sense to put note about it in the docs of the concat method. Though, not having concat(Stream..) overload would still remain unintuitive for many developers, including me Thanks everybody for the answers again Best regards On Wed, Sep 17, 2025 at 5:15?PM Pavel Rappo wrote: > > this would be a great quality of life improvement > > Is it such a useful use case, though? I mean, it's no different from > SequenceInputStream(...) or Math.min/max for that matter. I very > rarely have to do Math.min(a, Math(min(b, c)) or some such. And those > methods predate streams API by more than a decade. > > Separately, it's not just one method. Consider that `concat` is also > implemented in specialized streams such as IntStream, DoubleStream, > and LongStream. > > On Wed, Sep 17, 2025 at 2:58?PM Olexandr Rotan > wrote: > > > > Greetings to everyone on the list. > > > > When working on some routine tasks recently, I have encountered a, > seemingly to me, strange decision in design of Stream.concat method, > specifically the fact that it accepts exactly two streams. My concrete > example was something along the lines of > > > > var studentIds = ...; > > var teacherIds = ...; > > var partnerIds = ...; > > > > return Stream.concat( > > studentIds.stream(), > > teacherIds.stream(), > > partnerIds.stream() // oops, this one doesn't work > > ) > > > > so I had to transform concat to a rather ugly > > Stream.concat( > > studentIds.stream(), > > Stream.concat( > > teacherIds.stream(), > > partnerIds.stream() > > ) > > ) > > > > Later on I had to add 4th stream of a single element (Stream.of), and > this one became even more ugly > > > > When I first wrote third argument to concat and saw that IDE highlights > it as error, I was very surprised. This design seems inconsistent not only > with the whole java stdlib, but even with Stream.of static method of the > same class. Is there any particular reason why concat takes exactly to > arguments? > > > > I would say that, even if just in a form of sugar method that just does > reduce on array (varagrs) of streams, this would be a great quality of life > improvement, but I'm sure there also may be some room for performance > improvement. > > > > Of course, there are workarounds like Stream.of + flatmap, but: > > > > 1. It gets messy when trying to concat streams of literal elements set > (Stream.of) and streams of collections or arrays > > 2. It certainly has significant performance overhead > > 3. It still doesn't explain absence of varagrs overload of concat > > > > So, once again, is there any particular reason to restrict arguments > list to exactly two streams? If not, I would be happy to contribute > Stream.concat(Stream... streams) overload. > > > > Best regards > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prappo at openjdk.org Wed Sep 17 15:10:49 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 17 Sep 2025 15:10:49 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v7] In-Reply-To: References: Message-ID: > Please review this documentation-only change, which I believe does **NOT** require CSR. > > The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: > > * used a comma separator for some big integer values, to improve readability; > * fixed a few typos and grammar. > > While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. > > * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? > > Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) > > Are there any cases here where that distinction matters? > > * In many cases, the following phrase is used throughout documentation: > > > positive or negative > > While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? > > * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Remove CSR-triggering changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27296/files - new: https://git.openjdk.org/jdk/pull/27296/files/9ce42070..7c4cc716 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27296&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27296/head:pull/27296 PR: https://git.openjdk.org/jdk/pull/27296 From ihse at openjdk.org Wed Sep 17 15:14:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 15:14:16 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc Message-ID: The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). ------------- Commit messages: - Escape # in literals with \ - 8367859: Remove shell script from nio exception gensrc Changes: https://git.openjdk.org/jdk/pull/27338/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367859 Stats: 1058 lines in 11 files changed: 531 ins; 525 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27338/head:pull/27338 PR: https://git.openjdk.org/jdk/pull/27338 From ihse at openjdk.org Wed Sep 17 15:14:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 15:14:16 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). Some implementation notes: I considered writing a Java buildtool to read the existing `exceptions` files, but that seemed like a lot of work to keep up with a format that was not really ideal anyway, but was in fact a shell script snippet, disguised as a data file. The `*.java.template` method aligns better with most other gensrc solutions. This also makes it easier to get a better understanding of how the resulting file will look. As a matter of fact, the generated file with the old solution did not match up with how our files should look. I modified the template to follow this pattern. As an effect of this, all generated files has a diff (in whitespace or comments only) with this code compared to the old, like this: --- ReadOnlyBufferException.java 2025-09-11 11:55:45 +++ NEW/ReadOnlyBufferException.java 2025-09-12 17:40:57 @@ -1,6 +1,5 @@ /* - * Copyright (c) 2000, 2021, Oracle and/or its affiliates. All rights reserved. - * + * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -22,14 +21,10 @@ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. - * */ -// -- This file was mechanically generated: Do not edit! -- // - package java.nio; - /** * Unchecked exception thrown when a content-mutation method such as * put or compact is invoked upon a read-only buffer. @@ -48,5 +43,4 @@ * Constructs an instance of this class. */ public ReadOnlyBufferException() { } - } I consider this an improvement, not a bug. I also discovered a real bug. Due to how the old `exceptions` files were actually shell script snippets that were included and executed, proper care needed to be taken in how to handle quotes. This was not done for `IllegalCharsetNameException.java`. The `"` were eaten by the shell, so the generated Java code was: * legal charset name is used as such. instead of (the intended, and correct) * legal charset name is used as such. That is fixed with this PR. Apart from these changes, the generated files are identical before and after this PR. I don't understand what is going on with GHA. It works perfectly well on my local computer and Oracle's internal CI system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302348906 PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302581306 From ihse at openjdk.org Wed Sep 17 15:14:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 15:14:18 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: <7DZVTx-SNw-JWW4PdDlvpTSU0N7G5E5PKNcoXKYC-Nk=.d6675fe3-c6ce-4e40-85cc-2dedcf9a5cee@github.com> On Wed, 17 Sep 2025 11:36:07 GMT, Magnus Ihse Bursie wrote: > I don't understand what is going on with GHA. It works perfectly well on my local computer and Oracle's internal CI system. The answer to that is "GNU Make 4.3 is going on". I have a tentative fix... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3302785629 From bpb at openjdk.org Wed Sep 17 15:14:49 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Sep 2025 15:14:49 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 00:32:37 GMT, Brian Burkhalter wrote: >> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355342: Corrected a comment In `toRealPath`, the function `GetFinalPathNameByHandle` is not invoked unless links are being followed and a reparse point is encountered. Otherwise the real path is built up by analyzing the input path. I had actually already been wondering whether the canonicalized path should be checked for links before invoking `getFinalPath`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3303469478 From pavel.rappo at gmail.com Wed Sep 17 15:24:31 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 17 Sep 2025 16:24:31 +0100 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: Message-ID: FWIW, I too have fallen into this trap, and I did that even more than once. When my brain sees Path.endsWith(String), it somehow silently assumes that its semantic is that of String.endsWith(String). Of course, it isn't. What's worse, I learn about my mistake at runtime. But not because of an exception, no; I learn about it by getting unexpected results. There used to be a method that implemented the file extension thingy, but the commit was backed out. If it makes its way back in one form or another, it might help to avoid the trap: commit 10356e767a44632c5de142d4666bd85d4618bf71 Author: Brian Burkhalter Date: Wed Dec 7 18:54:18 2022 +0000 8298303: (fs) temporarily remove Path.getExtension Reviewed-by: smarks, alanb commit 50d91a31d495adf8e189d0188918f4ff22f93876 Author: Brian Burkhalter Date: Tue Nov 1 21:35:54 2022 +0000 8057113: (fs) Path should have a method to obtain the filename extension Reviewed-by: rriggs, lancea, mr, alanb On Wed, Sep 10, 2025 at 8:01?PM David Alayachew wrote: > > Hello @core-libs-dev, > > I have frequently run into the following pothole. > > Imagine the following directory setup. > > root/folderA/fileX.java > root/folderB/fileY.js > root/folderC/fileZ.html > > In this directory, let's say that we run the following code. > > Files > .walk(Path.of("root")) > .filter(path -> path.endsWith("html")) > .forEach(System.out::println) > ; > > One would expect only fileZ.html to be printed out, but nothing does. The reason why is because path.endsWith(String) is effectively an alias for path.endsWith(Path.of(String)). The confusion being that Path.of(someString) is looking for a file or a directory. Thus, since there is neither a file nor a folder called "html", the stream prints out nothing. > > This a very easy pothole to fall into, as the method name endsWith is the same as the one for String, thus, people will easily mix it up. And worse yet, depending on what they test with, they can easily confuse themselves into thinking they are good. For example, if I had done "fileZ.html" as my endsWith, I would have returned exactly what was expected, causing me to be misled. > > And as a cherry on the top, the syntactic benefit of this method is very little. Wrapping your string in a Path.of() means that you fall under the Path.endsWith(Path) overload, which is more explicit what it does. And at the very least, should give pause to the developer thinking it is doing String comparison, as they have to wrap their String in a Path, causing a moment to think. > > So, since this is a low value method and it causes high confusion, I vote that we deprecate it. > > Thoughts? > > Thank you for your time. > David Alayachew From asemenyuk at openjdk.org Wed Sep 17 15:26:28 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Sep 2025 15:26:28 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:51:46 GMT, Magnus Ihse Bursie wrote: >> src/java.base/windows/native/launcher/relauncher.c line 153: >> >>> 151: } >>> 152: >>> 153: // Our executable name (should not be quoted) >> >> ok here, because the full path is being explicitly passed to CreateProcess. >> If the command line is to be parsed and the executable path contains a space, CreateProcess does say it should be quoted. It would be good to have a test case with a space in the executable path. > > Indeed, this seems sus. I need to dig more into this. I recall initially quoting all arguments and then running into problems with the executable. Maybe it is that spaces needs to be quoted, but not other special characters. I'll check what you are doing in ProcessImpl.java and see if I can align my code to do the same. Passing arguments on Windows is tricky. We faced a similar challenge implementing shims in the Windows JDK installer. See [JDK-8266473](https://bugs.openjdk.org/browse/JDK-8266473), [JDK-8296383](https://bugs.openjdk.org/browse/JDK-8296383), and [JDK-8309489](https://bugs.openjdk.org/browse/JDK-8309489). All three CRs about the same issue until we finally fixed it properly. You need to encode command line args in a string suitable for passing to `CreateProcess()` function. The decoding algorithm is described at https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&redirectedfrom=MSDN. You need to implement the reverse algorithm. It is not officially documented at MSDN. Fortunately, somebody contributed it to the blog post at https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2355902250 From alanb at openjdk.org Wed Sep 17 15:28:24 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 15:28:24 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). I really dislike this. Can you please look at putting a template in java.nio.channels and java.nio.charsets for the exceptions in those packages? There will be a naming discussion to have on this too. Same thing for CharsetNameExceptions.java.template. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3303528178 From asemenyuk at openjdk.org Wed Sep 17 15:48:43 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Sep 2025 15:48:43 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v5] In-Reply-To: References: Message-ID: > Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. > > The new test is crafted to work (skip) in the environment where Ctrl+C signal emitted from the PowerShell script doesn't go through to a child process. > > Supplementary changes: > - Added convenience api to CfgFile; > - Fixed `TKit.waitForFileCreated()` function to work correctly when multiple files are monitored in the same directory and to call `close()` on the WatchService instance. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Call close() of a watch service instance ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27264/files - new: https://git.openjdk.org/jdk/pull/27264/files/d8ad4975..c63a7582 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27264&range=03-04 Stats: 38 lines in 1 file changed: 4 ins; 4 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/27264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27264/head:pull/27264 PR: https://git.openjdk.org/jdk/pull/27264 From naoto at openjdk.org Wed Sep 17 16:05:04 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Sep 2025 16:05:04 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:25:44 GMT, Alan Bateman wrote: > Alternatively, maybe we should just check into the exceptions in the src tree and avoid this. @naotoj @bplb, can you provide some opinion on this? I agree. Since those exceptions are not likely to change, It would be easier to maintain just to check-in those generated sources into the repository. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3303661328 From shade at openjdk.org Wed Sep 17 16:21:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Sep 2025 16:21:49 GMT Subject: RFR: 8367031: [backout] Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:41:11 GMT, Roger Riggs wrote: > > Is this a straight backout of [4ced4e7](https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624)? Shouldn't this be `[BACKOUT] ...` issue then? > > Yes, it is a straight backout; I can add the [backout] prefix to the regression title. Cool. Sorry for being overly retentive here, but as per [Guide](https://openjdk.org/guide/#backing-out-a-change), you need to name it: `[BACKOUT] Change java.time month/day field types to 'byte'` ;) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303720097 From naoto at openjdk.org Wed Sep 17 16:26:36 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Sep 2025 16:26:36 GMT Subject: RFR: 8367031: [backout] Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: <8v7M7hsGV69vJUhx_FRwK7sK63iWM4ABJY2fdoSfRko=.44b74e61-6ea7-44aa-b958-313675d74f19@github.com> On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27346#pullrequestreview-3235275913 From rriggs at openjdk.org Wed Sep 17 16:30:37 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 16:30:37 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v7] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:10:49 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Remove CSR-triggering changes Keeping the change to typos removes the necessity of the the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3303752478 From iris at openjdk.org Wed Sep 17 16:40:01 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 17 Sep 2025 16:40:01 GMT Subject: RFR: 8367031: [backout] Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: <2EgDDsqc6rMkFtLQbhNGAsNSFFsTI6D7NOm0F-KWFtY=.7eaf0b2b-15ec-4c74-b26a-4cf766d7d928@github.com> On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27346#pullrequestreview-3235320383 From rriggs at openjdk.org Wed Sep 17 16:46:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 16:46:39 GMT Subject: RFR: 8367031: [backout] Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:19:31 GMT, Aleksey Shipilev wrote: >>> Is this a straight backout of [4ced4e7](https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624)? Shouldn't this be `[BACKOUT] ...` issue then? >> >> Yes, it is a straight backout; I can add the [backout] prefix to the regression title. > >> > Is this a straight backout of [4ced4e7](https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624)? Shouldn't this be `[BACKOUT] ...` issue then? >> >> Yes, it is a straight backout; I can add the [backout] prefix to the regression title. > > Cool. Sorry for being overly retentive here, but as per [Guide](https://openjdk.org/guide/#backing-out-a-change), you need to name it: `[BACKOUT] Change java.time month/day field types to 'byte'` ;) @shipilev I can create a new issue with exactly the prescribed text. But changing the purpose of the issue that was filed to be a simple back-out seems like its loosing information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303802334 From dfuchs at openjdk.org Wed Sep 17 16:58:04 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 17 Sep 2025 16:58:04 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: - merge latest changes from master branch - merge latest changes from master branch - http3: CSR review feedback - merge latest changes from master branch - modify http3 test timeouts - qpack - take knownReceivedCount into account during DT entries eviction - merge latest changes from master branch - http3: fix at since - merge latest http3 changes - Remove unused variables - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=17 Stats: 105854 lines in 474 files changed: 103017 ins; 1337 del; 1500 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From shade at openjdk.org Wed Sep 17 16:58:57 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Sep 2025 16:58:57 GMT Subject: RFR: 8367031: [backout] Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:19:31 GMT, Aleksey Shipilev wrote: >>> Is this a straight backout of [4ced4e7](https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624)? Shouldn't this be `[BACKOUT] ...` issue then? >> >> Yes, it is a straight backout; I can add the [backout] prefix to the regression title. > >> > Is this a straight backout of [4ced4e7](https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624)? Shouldn't this be `[BACKOUT] ...` issue then? >> >> Yes, it is a straight backout; I can add the [backout] prefix to the regression title. > > Cool. Sorry for being overly retentive here, but as per [Guide](https://openjdk.org/guide/#backing-out-a-change), you need to name it: `[BACKOUT] Change java.time month/day field types to 'byte'` ;) > @shipilev I can create a new issue with exactly the prescribed text. But changing the purpose of the issue that was filed to be a simple back-out seems like its loosing information. No need to create new issues. Guide mentions "Alternative 2": you just convert this "investigation" issue into "backout" issue, and move it to be a subtask of the original issue. There is no loss of information, just a few metadata changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303828868 From liach at openjdk.org Wed Sep 17 16:58:58 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Sep 2025 16:58:58 GMT Subject: RFR: 8367031: [backout] Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:52:09 GMT, Aleksey Shipilev wrote: >>> > Is this a straight backout of [4ced4e7](https://github.com/openjdk/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624)? Shouldn't this be `[BACKOUT] ...` issue then? >>> >>> Yes, it is a straight backout; I can add the [backout] prefix to the regression title. >> >> Cool. Sorry for being overly retentive here, but as per [Guide](https://openjdk.org/guide/#backing-out-a-change), you need to name it: `[BACKOUT] Change java.time month/day field types to 'byte'` ;) > >> @shipilev I can create a new issue with exactly the prescribed text. But changing the purpose of the issue that was filed to be a simple back-out seems like its loosing information. > > No need to create new issues. Guide mentions "Alternative 2": you just convert this "investigation" issue into "backout" issue, and move it to be a subtask of the original issue. There is no loss of information, just a few metadata changes? @shipilev FYI this issue already has a release note subtask, so the issue itself cannot be converted to a subtask. We might need to move the release note too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303840514 From shade at openjdk.org Wed Sep 17 17:03:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Sep 2025 17:03:00 GMT Subject: RFR: 8367031: [backout] Regression in serialization of LocalDate class objects In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Aw, release note is present. Well, that's one of those corner cases. Back to square one then: drop the `[backout]` from synopsis, but mention in the comments in the original issue that it was effectively completely backed out by this one. I remember we did a few issues like that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3303854212 From alanb at openjdk.org Wed Sep 17 17:58:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 17:58:44 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:12:01 GMT, Brian Burkhalter wrote: > I had actually already been wondering whether the canonicalized path should be checked for links before invoking `getFinalPath`. I assume you've checked the flags that can be provided to GetFinalPathNameByHandleW and that there isn't a solution there. In that case, I think it would be better to check the attributes in the WIN32_FIND_DATA to see if it's a reparse point. That would mean deeper changes but should mean you avoid the post-processing the result from getFinalPath, which I think is a bit too hacky to have in this code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3304025676 From alanb at openjdk.org Wed Sep 17 18:05:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 18:05:03 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 I assume you'll do another run of all tiers before integrating. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3235634542 From rriggs at openjdk.org Wed Sep 17 18:11:20 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 18:11:20 GMT Subject: RFR: 8367031: [backout] Change java.time month/day field types to 'byte' In-Reply-To: References: Message-ID: <4vCKX2sztBjsgGbv9DywsgovPHlc_xVkyXVDbwIAejU=.5807e04e-dfaa-4288-9a6d-b6c17fa7f411@github.com> On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. Updated the title of 8367031, it is moved to a subtask of the original 8334742. The release note is now a subtask of 8334742, which still seems like the relevant parent. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27346#issuecomment-3304062859 From ihse at openjdk.org Wed Sep 17 18:42:01 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 18:42:01 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). I'm glad to hear you say that. That was my initial thinking also, but since it was not done that way originally, I thought it would not be acceptable. I think that is a much better solution. I'll create a new PR with checked-in code, but I'll keep this open for the time being, if it turns out a generated solution is preferred. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304151588 From ihse at openjdk.org Wed Sep 17 19:00:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 19:00:55 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). See https://github.com/openjdk/jdk/pull/27352. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304203859 From ihse at openjdk.org Wed Sep 17 19:06:50 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 19:06:50 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: <7uO975LP8DrKcIOGtAus5lgZIJD69QDs1ofB2COroIM=.fa4c9ae0-366b-471d-9c8b-14ee8b6e7374@github.com> On Wed, 17 Sep 2025 15:23:47 GMT, Alexey Semenyuk wrote: >> Indeed, this seems sus. I need to dig more into this. I recall initially quoting all arguments and then running into problems with the executable. Maybe it is that spaces needs to be quoted, but not other special characters. I'll check what you are doing in ProcessImpl.java and see if I can align my code to do the same. > > Passing arguments on Windows is tricky. We faced a similar challenge implementing shims in the Windows JDK installer. See [JDK-8266473](https://bugs.openjdk.org/browse/JDK-8266473), [JDK-8296383](https://bugs.openjdk.org/browse/JDK-8296383), and [JDK-8309489](https://bugs.openjdk.org/browse/JDK-8309489). All three CRs about the same issue until we finally fixed it properly. > > You need to encode command line args in a string suitable for passing to `CreateProcess()` function. The decoding algorithm is described at https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&redirectedfrom=MSDN. You need to implement the reverse algorithm. It is not officially documented at MSDN. Fortunately, somebody contributed it to the blog post at https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way. Yes, I've read that blog post, tried to implement it and credited in the source code. :-) The discussion was if the executable name should be treated differently than the command line arguments. I've added code do explicitly do this, but I don't any longer recall why (this was originally developed back in like May or April, it's just been sitting on the shelf waiting for me to get to the finish line). I do recall that I ran into problems when I treated the executable name as any other argument though, so *something* special needs to be done about it. But reading this blog post again, it seems that it claims that the program name should be quoted the same way as well. I'll try to go back in time and check my notes, command line histories and old commits to see if I can figure out what kind of issue I ran into. Otherwise the correct solution seem to be to quote the program name the same way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2356490736 From almatvee at openjdk.org Wed Sep 17 19:11:46 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 17 Sep 2025 19:11:46 GMT Subject: RFR: 8365790: Shutdown hook for application image does not work on Windows [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:48:43 GMT, Alexey Semenyuk wrote: >> Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. >> >> The new test is crafted to work (skip) in the environment where Ctrl+C signal emitted from the PowerShell script doesn't go through to a child process. >> >> Supplementary changes: >> - Added convenience api to CfgFile; >> - Fixed `TKit.waitForFileCreated()` function to work correctly when multiple files are monitored in the same directory and to call `close()` on the WatchService instance. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Call close() of a watch service instance Latest changes looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27264#pullrequestreview-3235884435 From asmehra at openjdk.org Wed Sep 17 19:11:48 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 17 Sep 2025 19:11:48 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:40:48 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added logging about @AOTSafeClassInitializer classes that have not been initialized > Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 src/hotspot/share/cds/aotClassInitializer.cpp line 53: > 51: > 52: if (ik->force_aot_initialization()) { > 53: assert(ik->is_initialized(), "must have been initialized before this check"); Is it not possible for a jdk class to be loaded but not initialized during an application run? If such a jdk class is marked with AOTInitialize annotation, this assert would trigger during the assembly phase. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3304237468 PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2356493896 From cstein at openjdk.org Wed Sep 17 19:24:13 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 17 Sep 2025 19:24:13 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:02:32 GMT, Alan Bateman wrote: > I assume you'll do another run of all tiers before integrating. Yes. A run of tier 1-9 is in progress, with tier 1-5 already looking very promising. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3304276125 From asemenyuk at openjdk.org Wed Sep 17 19:25:24 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Sep 2025 19:25:24 GMT Subject: Integrated: 8365790: Shutdown hook for application image does not work on Windows In-Reply-To: References: Message-ID: <7j7seyZnAC7LEc9aKhVYFoTFgbqKN95kIAStRY7EBV0=.6e0730d1-2312-454d-b39d-524bf5d9455c@github.com> On Fri, 12 Sep 2025 20:48:22 GMT, Alexey Semenyuk wrote: > Disable the default handling of Ctrl+C in the parent app launcher process to let the child app launcher running JVM handle it. Add corresponding test case. > > The new test is crafted to work (skip) in the environment where Ctrl+C signal emitted from the PowerShell script doesn't go through to a child process. > > Supplementary changes: > - Added convenience api to CfgFile; > - Fixed `TKit.waitForFileCreated()` function to work correctly when multiple files are monitored in the same directory and to call `close()` on the WatchService instance. This pull request has now been integrated. Changeset: f7ce3a1b Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/f7ce3a1b5f38143f17b5015ca5b714ec0e708f54 Stats: 387 lines in 8 files changed: 346 ins; 4 del; 37 mod 8365790: Shutdown hook for application image does not work on Windows Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/27264 From asemenyuk at openjdk.org Wed Sep 17 19:31:10 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Sep 2025 19:31:10 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: <7uO975LP8DrKcIOGtAus5lgZIJD69QDs1ofB2COroIM=.fa4c9ae0-366b-471d-9c8b-14ee8b6e7374@github.com> References: <7uO975LP8DrKcIOGtAus5lgZIJD69QDs1ofB2COroIM=.fa4c9ae0-366b-471d-9c8b-14ee8b6e7374@github.com> Message-ID: <9ure1PfDyf7t8yThlpULus67vOnrpObBdQqg0CPeREQ=.6ed5d91f-b2e2-4711-914f-8445eb972619@github.com> On Wed, 17 Sep 2025 19:04:02 GMT, Magnus Ihse Bursie wrote: >> Passing arguments on Windows is tricky. We faced a similar challenge implementing shims in the Windows JDK installer. See [JDK-8266473](https://bugs.openjdk.org/browse/JDK-8266473), [JDK-8296383](https://bugs.openjdk.org/browse/JDK-8296383), and [JDK-8309489](https://bugs.openjdk.org/browse/JDK-8309489). All three CRs about the same issue until we finally fixed it properly. >> >> You need to encode command line args in a string suitable for passing to `CreateProcess()` function. The decoding algorithm is described at https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&redirectedfrom=MSDN. You need to implement the reverse algorithm. It is not officially documented at MSDN. Fortunately, somebody contributed it to the blog post at https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way. > > Yes, I've read that blog post, tried to implement it and credited in the source code. :-) > > The discussion was if the executable name should be treated differently than the command line arguments. I've added code do explicitly do this, but I don't any longer recall why (this was originally developed back in like May or April, it's just been sitting on the shelf waiting for me to get to the finish line). I do recall that I ran into problems when I treated the executable name as any other argument though, so *something* special needs to be done about it. > > But reading this blog post again, it seems that it claims that the program name should be quoted the same way as well. I'll try to go back in time and check my notes, command line histories and old commits to see if I can figure out what kind of issue I ran into. Otherwise the correct solution seem to be to quote the program name the same way. Oh, my bad :) I didn't dive into the source code. I came across this discussion and recalled a similar issue in the installer code. We quote the program name in the installer shims. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2356541157 From ihse at openjdk.org Wed Sep 17 19:34:44 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 19:34:44 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: <9ure1PfDyf7t8yThlpULus67vOnrpObBdQqg0CPeREQ=.6ed5d91f-b2e2-4711-914f-8445eb972619@github.com> References: <7uO975LP8DrKcIOGtAus5lgZIJD69QDs1ofB2COroIM=.fa4c9ae0-366b-471d-9c8b-14ee8b6e7374@github.com> <9ure1PfDyf7t8yThlpULus67vOnrpObBdQqg0CPeREQ=.6ed5d91f-b2e2-4711-914f-8445eb972619@github.com> Message-ID: On Wed, 17 Sep 2025 19:27:57 GMT, Alexey Semenyuk wrote: >> Yes, I've read that blog post, tried to implement it and credited in the source code. :-) >> >> The discussion was if the executable name should be treated differently than the command line arguments. I've added code do explicitly do this, but I don't any longer recall why (this was originally developed back in like May or April, it's just been sitting on the shelf waiting for me to get to the finish line). I do recall that I ran into problems when I treated the executable name as any other argument though, so *something* special needs to be done about it. >> >> But reading this blog post again, it seems that it claims that the program name should be quoted the same way as well. I'll try to go back in time and check my notes, command line histories and old commits to see if I can figure out what kind of issue I ran into. Otherwise the correct solution seem to be to quote the program name the same way. > > Oh, my bad :) I didn't dive into the source code. I came across this discussion and recalled a similar issue in the installer code. > > We quote the program name in the installer shims. No worries, that blog post is essential reading for anyone working with command line args on Windows, and it is a good thing that you try to spread knowledge about it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2356550461 From rriggs at openjdk.org Wed Sep 17 19:52:32 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Sep 2025 19:52:32 GMT Subject: Integrated: 8367031: [backout] Change java.time month/day field types to 'byte' In-Reply-To: References: Message-ID: <7qUOwtFxS4ZKprUxk7wbX_4BLeqUjVLwmMgzvlUJp1U=.26f5d6b0-c626-4894-8cc2-9f550a7ddb3c@github.com> On Wed, 17 Sep 2025 13:39:18 GMT, Roger Riggs wrote: > This reverts commit 4ced4e73fc0a517df826860839681004bb67e624. > > Restore the previous field types to maintain compatibility with previous releases of the serialized form > of classes of java.time. > The classes reverted are LocalDate, MonthDay, YearMonth, and HijrahDate. This pull request has now been integrated. Changeset: 0756ecb2 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/0756ecb214b8ab76cb69f354063d153b72f978c2 Stats: 17 lines in 4 files changed: 0 ins; 0 del; 17 mod 8367031: [backout] Change java.time month/day field types to 'byte' Reviewed-by: alanb, liach, naoto, iris ------------- PR: https://git.openjdk.org/jdk/pull/27346 From rotanolexandr842 at gmail.com Wed Sep 17 20:14:55 2025 From: rotanolexandr842 at gmail.com (Olexandr Rotan) Date: Wed, 17 Sep 2025 23:14:55 +0300 Subject: Stream.concat with varagrs In-Reply-To: References: Message-ID: So i have played around a bit and managed to come up with some implementation based on array of streams, you can find it here: https://github.com/Evemose/nconcat/blob/master/src/main/java/nconcat/NConcatSpliterator.java I have also added a small benchmark to the project, and the numbers are: Benchmark (streamCount) Mode Cnt Score Error Units NConcatBenchmark.nConcatFindFirst 4 avgt 10 131.616 ? 15.474 ns/op NConcatBenchmark.nConcatFindFirst 8 avgt 10 187.929 ? 6.544 ns/op NConcatBenchmark.nConcatFindFirst 16 avgt 10 322.342 ? 6.940 ns/op NConcatBenchmark.nConcatFindFirst 32 avgt 10 659.856 ? 85.509 ns/op NConcatBenchmark.nConcatFindFirst 64 avgt 10 1214.133 ? 22.156 ns/op NConcatBenchmark.nConcatMethod 4 avgt 10 1910.150 ? 25.269 ns/op NConcatBenchmark.nConcatMethod 8 avgt 10 3865.364 ? 112.536 ns/op NConcatBenchmark.nConcatMethod 16 avgt 10 7743.097 ? 74.655 ns/op NConcatBenchmark.nConcatMethod 32 avgt 10 15840.551 ? 440.659 ns/op NConcatBenchmark.nConcatMethod 64 avgt 10 32891.336 ? 1122.630 ns/op NConcatBenchmark.nConcatToListWithFilter 4 avgt 10 9527.120 ? 376.325 ns/op NConcatBenchmark.nConcatToListWithFilter 8 avgt 10 20260.027 ? 552.444 ns/op NConcatBenchmark.nConcatToListWithFilter 16 avgt 10 44724.856 ? 5040.069 ns/op NConcatBenchmark.nConcatToListWithFilter 32 avgt 10 82577.518 ? 2050.955 ns/op NConcatBenchmark.nConcatToListWithFilter 64 avgt 10 181460.219 ? 20809.669 ns/op NConcatBenchmark.nconcatToList 4 avgt 10 9268.814 ? 712.883 ns/op NConcatBenchmark.nconcatToList 8 avgt 10 18164.147 ? 786.803 ns/op NConcatBenchmark.nconcatToList 16 avgt 10 35146.891 ? 966.871 ns/op NConcatBenchmark.nconcatToList 32 avgt 10 68944.262 ? 5321.730 ns/op NConcatBenchmark.nconcatToList 64 avgt 10 136845.984 ? 3491.562 ns/op NConcatBenchmark.standardStreamConcat 4 avgt 10 1951.522 ? 85.130 ns/op NConcatBenchmark.standardStreamConcat 8 avgt 10 3990.410 ? 190.517 ns/op NConcatBenchmark.standardStreamConcat 16 avgt 10 8599.869 ? 685.878 ns/op NConcatBenchmark.standardStreamConcat 32 avgt 10 17923.603 ? 361.874 ns/op NConcatBenchmark.standardStreamConcat 64 avgt 10 46797.408 ? 4458.069 ns/op NConcatBenchmark.standardStreamConcatFindFirst 4 avgt 10 125.192 ? 3.123 ns/op NConcatBenchmark.standardStreamConcatFindFirst 8 avgt 10 303.791 ? 8.670 ns/op NConcatBenchmark.standardStreamConcatFindFirst 16 avgt 10 907.429 ? 52.620 ns/op NConcatBenchmark.standardStreamConcatFindFirst 32 avgt 10 2964.749 ? 320.141 ns/op NConcatBenchmark.standardStreamConcatFindFirst 64 avgt 10 11749.653 ? 189.300 ns/op NConcatBenchmark.standardStreamConcatToList 4 avgt 10 7059.642 ? 740.735 ns/op NConcatBenchmark.standardStreamConcatToList 8 avgt 10 13714.980 ? 250.208 ns/op NConcatBenchmark.standardStreamConcatToList 16 avgt 10 27028.052 ? 565.047 ns/op NConcatBenchmark.standardStreamConcatToList 32 avgt 10 53537.731 ? 853.363 ns/op NConcatBenchmark.standardStreamConcatToList 64 avgt 10 105847.755 ? 3179.918 ns/op NConcatBenchmark.standardStreamConcatToListWithFilter 4 avgt 10 9736.527 ? 154.817 ns/op NConcatBenchmark.standardStreamConcatToListWithFilter 8 avgt 10 20607.061 ? 713.083 ns/op NConcatBenchmark.standardStreamConcatToListWithFilter 16 avgt 10 41241.199 ? 1171.672 ns/op NConcatBenchmark.standardStreamConcatToListWithFilter 32 avgt 10 83029.244 ? 1843.176 ns/op NConcatBenchmark.standardStreamConcatToListWithFilter 64 avgt 10 182349.009 ? 11282.832 ns/op Basically, the conclusion is following (guilty of using AI for summarizing): The comprehensive benchmarks reveal that *NConcat significantly outperforms > the standard library for processing-intensive operations* while trailing > in simple collection scenarios. For short-circuit operations like > findFirst(), NConcat delivers 38-90% better performance as stream count > increases, reaching nearly 10x faster execution at 64 streams due to > superior scaling (19ns/stream vs 184ns/stream). Full traversal operations > like forEach consistently favor NConcat by 2-30%, with the advantage > growing at scale. However, simple collection operations (toList()) > consistently run 22-24% faster with the standard library across all stream > counts. I have tried multiple approaches to optimize toList with know size of all sub-streams (which is clearly the reason why standard implementation wins here), and am sure that there is still plenty of room for improvement, especially in parallel, but the takeaway is, even a naive implementation like mine could bring a significant performance improvement to the table in early short-circuiting and full traversal cases that do not depend on size of the spliterator. Besides the performance part, of course, the most significant advantage of my proposal, as I think, is still developer experience, both reading and writing stream code. Please let me know your thoughts on the results of prototype and possible ways forward. Best regards On Wed, Sep 17, 2025 at 6:04?PM Olexandr Rotan wrote: > Hello everyone! Thanks for your responses > > I will start of by answering to Viktor > > I guess a "simple" implementation of an N-ary concat could work, but it >> would have performance implications (think a recursive use of >> Stream.concat()) > > > I too find just the addition of small reduction-performing sugar methods > rather unsatisfactory and most certainly not bringing enough value to be > considered a valuable addition. Moreover, I have not checked it myself, but > I would dare to guess that popular utility libraries such as Guava or > Apache Commons already provide this sort of functionality in their utility > classes. Though, if this method could bring some significant performance > benefits, I think it may be a valuable candidate to consider. Though, to me > as a user, the main value would be uniformity of the API and ease of use > and read. The main reason I am writing about this in the first place is the > unintuitive inconsistency with many other static methods-creators that > happily accept varargs > > I may play around with this spliterator code you have linked to to see if > I could make it generalized for arrays of streams > > Now, answering to Pavel > > Is it such a useful use case, though? I mean, it's no different from >> SequenceInputStream(...) or Math.min/max for that matter. I very rarely >> have to do Math.min(a, Math(min(b, c)) or some such. > > > I certainly see your point, but I would dare to say that most applications > rely on the streams much more than SequenceInputStream and Math classes, > and their lookalikes. Stream.concat is primarily a way to merge a few > datasource outputs into one, for later uniform processing, which, in the > nutshell, is one of the most common tasks in data-centric applications. Of > course, not every such use case has characteristics that incline developers > to use Stream.concat, such as combination of Stream.of and > Collection.stream() sources, and even if they do, not every case that fits > previous requirement requires to merge more than 2 sources. However, for > mid-to-large scale apps, for which java is known the most, I would say it's > fairly common. I went over our codebase and found that there were at least > 10+ usages of concat, and a few of them followed this kinda ugly pattern of > nested concates. > > Separately, it's not just one method. Consider that `concat` is also >> implemented in specialized streams such as IntStream, DoubleStream, and >> LongStream. > > > This is unfortunate, but I would dare to say that once Reference > spliterrator is implemented, others may also be derived by analogy fairly > quickly > > And last but not least, answering Daniel > > Not immediately obvious but you can create a Stream> using >> Stream.of and reduce that using Stream::concat to obtain a Stream. > > Something along those lines: > > ``` >> var stream = Stream.of(Stream.of(1,2,3), Stream.of(4), Stream.of(5, 6, >> 7, 8)).reduce(Stream.empty(), Stream::concat, Stream::concat); > > > This is what I meant by "reduction-like" implementation, which is fairly > straightforward, but just from the looks of it, one could assume that this > solution will surely have performance consequences, even if using flatmap > insead of reduce. Not sure though, how often people would want to use such > approach on the array of streams huge enough for the performance difference > to be noticable, though I would assume that there is a non-linear scale of > consumed time and resources from the length of streams array due to the > implementation of concat method. > > Nevertheless, this is an acceptable workaround for such cases, even though > not the most readable one. Even if this approach is accepted as sufficient > for such cases of n-sized array of streams merging, It would probably make > some sense to put note about it in the docs of the concat method. Though, > not having concat(Stream..) overload would still remain unintuitive for > many developers, including me > > Thanks everybody for the answers again > > Best regards > > On Wed, Sep 17, 2025 at 5:15?PM Pavel Rappo wrote: > >> > this would be a great quality of life improvement >> >> Is it such a useful use case, though? I mean, it's no different from >> SequenceInputStream(...) or Math.min/max for that matter. I very >> rarely have to do Math.min(a, Math(min(b, c)) or some such. And those >> methods predate streams API by more than a decade. >> >> Separately, it's not just one method. Consider that `concat` is also >> implemented in specialized streams such as IntStream, DoubleStream, >> and LongStream. >> >> On Wed, Sep 17, 2025 at 2:58?PM Olexandr Rotan >> wrote: >> > >> > Greetings to everyone on the list. >> > >> > When working on some routine tasks recently, I have encountered a, >> seemingly to me, strange decision in design of Stream.concat method, >> specifically the fact that it accepts exactly two streams. My concrete >> example was something along the lines of >> > >> > var studentIds = ...; >> > var teacherIds = ...; >> > var partnerIds = ...; >> > >> > return Stream.concat( >> > studentIds.stream(), >> > teacherIds.stream(), >> > partnerIds.stream() // oops, this one doesn't work >> > ) >> > >> > so I had to transform concat to a rather ugly >> > Stream.concat( >> > studentIds.stream(), >> > Stream.concat( >> > teacherIds.stream(), >> > partnerIds.stream() >> > ) >> > ) >> > >> > Later on I had to add 4th stream of a single element (Stream.of), and >> this one became even more ugly >> > >> > When I first wrote third argument to concat and saw that IDE highlights >> it as error, I was very surprised. This design seems inconsistent not only >> with the whole java stdlib, but even with Stream.of static method of the >> same class. Is there any particular reason why concat takes exactly to >> arguments? >> > >> > I would say that, even if just in a form of sugar method that just does >> reduce on array (varagrs) of streams, this would be a great quality of life >> improvement, but I'm sure there also may be some room for performance >> improvement. >> > >> > Of course, there are workarounds like Stream.of + flatmap, but: >> > >> > 1. It gets messy when trying to concat streams of literal elements set >> (Stream.of) and streams of collections or arrays >> > 2. It certainly has significant performance overhead >> > 3. It still doesn't explain absence of varagrs overload of concat >> > >> > So, once again, is there any particular reason to restrict arguments >> list to exactly two streams? If not, I would be happy to contribute >> Stream.concat(Stream... streams) overload. >> > >> > Best regards >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psandoz at openjdk.org Wed Sep 17 20:19:40 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 17 Sep 2025 20:19:40 GMT Subject: RFR: 8367787: Expand use of representation equivalence terminology in Float16 In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 20:33:00 GMT, Joe Darcy wrote: > Analogous to recent updates made in Float and Double, along with a double -> Float16 typo fix. Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27322#pullrequestreview-3236127418 From bpb at openjdk.org Wed Sep 17 20:19:45 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Sep 2025 20:19:45 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 17:56:25 GMT, Alan Bateman wrote: > I assume you've checked the flags that can be provided to GetFinalPathNameByHandleW and that there isn't a solution there. Yes, I checked all combinations before pursuing this change. There's no help there. > In that case, I think it would be better to check the attributes in the WIN32_FIND_DATA to see if it's a reparse point. That would mean deeper changes Will check it out. > but should mean you avoid the post-processing the result from getFinalPath, which I think is a bit too hacky to have in this code. I think it's correct but I agree about its "hackiness." ------------- PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3304437884 From emcmanus at google.com Wed Sep 17 20:21:18 2025 From: emcmanus at google.com (=?UTF-8?Q?=C3=89amonn_McManus?=) Date: Wed, 17 Sep 2025 13:21:18 -0700 Subject: Stream.concat with varagrs In-Reply-To: References: Message-ID: Guava has a Streams.concat method that may suggest implementation possibilities. On Wed, 17 Sept 2025 at 13:16, Olexandr Rotan wrote: > So i have played around a bit and managed to come up with some > implementation based on array of streams, you can find it here: > https://github.com/Evemose/nconcat/blob/master/src/main/java/nconcat/NConcatSpliterator.java > > I have also added a small benchmark to the project, and the numbers are: > > Benchmark (streamCount) Mode > Cnt Score Error Units > NConcatBenchmark.nConcatFindFirst 4 avgt > 10 131.616 ? 15.474 ns/op > NConcatBenchmark.nConcatFindFirst 8 avgt > 10 187.929 ? 6.544 ns/op > NConcatBenchmark.nConcatFindFirst 16 avgt > 10 322.342 ? 6.940 ns/op > NConcatBenchmark.nConcatFindFirst 32 avgt > 10 659.856 ? 85.509 ns/op > NConcatBenchmark.nConcatFindFirst 64 avgt > 10 1214.133 ? 22.156 ns/op > NConcatBenchmark.nConcatMethod 4 avgt > 10 1910.150 ? 25.269 ns/op > NConcatBenchmark.nConcatMethod 8 avgt > 10 3865.364 ? 112.536 ns/op > NConcatBenchmark.nConcatMethod 16 avgt > 10 7743.097 ? 74.655 ns/op > NConcatBenchmark.nConcatMethod 32 avgt > 10 15840.551 ? 440.659 ns/op > NConcatBenchmark.nConcatMethod 64 avgt > 10 32891.336 ? 1122.630 ns/op > NConcatBenchmark.nConcatToListWithFilter 4 avgt > 10 9527.120 ? 376.325 ns/op > NConcatBenchmark.nConcatToListWithFilter 8 avgt > 10 20260.027 ? 552.444 ns/op > NConcatBenchmark.nConcatToListWithFilter 16 avgt > 10 44724.856 ? 5040.069 ns/op > NConcatBenchmark.nConcatToListWithFilter 32 avgt > 10 82577.518 ? 2050.955 ns/op > NConcatBenchmark.nConcatToListWithFilter 64 avgt > 10 181460.219 ? 20809.669 ns/op > NConcatBenchmark.nconcatToList 4 avgt > 10 9268.814 ? 712.883 ns/op > NConcatBenchmark.nconcatToList 8 avgt > 10 18164.147 ? 786.803 ns/op > NConcatBenchmark.nconcatToList 16 avgt > 10 35146.891 ? 966.871 ns/op > NConcatBenchmark.nconcatToList 32 avgt > 10 68944.262 ? 5321.730 ns/op > NConcatBenchmark.nconcatToList 64 avgt > 10 136845.984 ? 3491.562 ns/op > NConcatBenchmark.standardStreamConcat 4 avgt > 10 1951.522 ? 85.130 ns/op > NConcatBenchmark.standardStreamConcat 8 avgt > 10 3990.410 ? 190.517 ns/op > NConcatBenchmark.standardStreamConcat 16 avgt > 10 8599.869 ? 685.878 ns/op > NConcatBenchmark.standardStreamConcat 32 avgt > 10 17923.603 ? 361.874 ns/op > NConcatBenchmark.standardStreamConcat 64 avgt > 10 46797.408 ? 4458.069 ns/op > NConcatBenchmark.standardStreamConcatFindFirst 4 avgt > 10 125.192 ? 3.123 ns/op > NConcatBenchmark.standardStreamConcatFindFirst 8 avgt > 10 303.791 ? 8.670 ns/op > NConcatBenchmark.standardStreamConcatFindFirst 16 avgt > 10 907.429 ? 52.620 ns/op > NConcatBenchmark.standardStreamConcatFindFirst 32 avgt > 10 2964.749 ? 320.141 ns/op > NConcatBenchmark.standardStreamConcatFindFirst 64 avgt > 10 11749.653 ? 189.300 ns/op > NConcatBenchmark.standardStreamConcatToList 4 avgt > 10 7059.642 ? 740.735 ns/op > NConcatBenchmark.standardStreamConcatToList 8 avgt > 10 13714.980 ? 250.208 ns/op > NConcatBenchmark.standardStreamConcatToList 16 avgt > 10 27028.052 ? 565.047 ns/op > NConcatBenchmark.standardStreamConcatToList 32 avgt > 10 53537.731 ? 853.363 ns/op > NConcatBenchmark.standardStreamConcatToList 64 avgt > 10 105847.755 ? 3179.918 ns/op > NConcatBenchmark.standardStreamConcatToListWithFilter 4 avgt > 10 9736.527 ? 154.817 ns/op > NConcatBenchmark.standardStreamConcatToListWithFilter 8 avgt > 10 20607.061 ? 713.083 ns/op > NConcatBenchmark.standardStreamConcatToListWithFilter 16 avgt > 10 41241.199 ? 1171.672 ns/op > NConcatBenchmark.standardStreamConcatToListWithFilter 32 avgt > 10 83029.244 ? 1843.176 ns/op > NConcatBenchmark.standardStreamConcatToListWithFilter 64 avgt > 10 182349.009 ? 11282.832 ns/op > > Basically, the conclusion is following (guilty of using AI for > summarizing): > > The comprehensive benchmarks reveal that *NConcat significantly >> outperforms the standard library for processing-intensive operations* >> while trailing in simple collection scenarios. For short-circuit operations >> like findFirst(), NConcat delivers 38-90% better performance as stream >> count increases, reaching nearly 10x faster execution at 64 streams due to >> superior scaling (19ns/stream vs 184ns/stream). Full traversal operations >> like forEach consistently favor NConcat by 2-30%, with the advantage >> growing at scale. However, simple collection operations (toList()) >> consistently run 22-24% faster with the standard library across all stream >> counts. > > > > I have tried multiple approaches to optimize toList with know size of all > sub-streams (which is clearly the reason why standard implementation wins > here), and am sure that there is still plenty of room for improvement, > especially in parallel, but the takeaway is, even a naive implementation > like mine could bring a significant performance improvement to the table in > early short-circuiting and full traversal cases that do not depend on size > of the spliterator. > > Besides the performance part, of course, the most significant advantage of > my proposal, as I think, is still developer experience, both reading and > writing stream code. > > Please let me know your thoughts on the results of prototype and possible > ways forward. > > Best regards > > On Wed, Sep 17, 2025 at 6:04?PM Olexandr Rotan > wrote: > >> Hello everyone! Thanks for your responses >> >> I will start of by answering to Viktor >> >> I guess a "simple" implementation of an N-ary concat could work, but it >>> would have performance implications (think a recursive use of >>> Stream.concat()) >> >> >> I too find just the addition of small reduction-performing sugar methods >> rather unsatisfactory and most certainly not bringing enough value to be >> considered a valuable addition. Moreover, I have not checked it myself, but >> I would dare to guess that popular utility libraries such as Guava or >> Apache Commons already provide this sort of functionality in their utility >> classes. Though, if this method could bring some significant performance >> benefits, I think it may be a valuable candidate to consider. Though, to me >> as a user, the main value would be uniformity of the API and ease of use >> and read. The main reason I am writing about this in the first place is the >> unintuitive inconsistency with many other static methods-creators that >> happily accept varargs >> >> I may play around with this spliterator code you have linked to to see if >> I could make it generalized for arrays of streams >> >> Now, answering to Pavel >> >> Is it such a useful use case, though? I mean, it's no different from >>> SequenceInputStream(...) or Math.min/max for that matter. I very rarely >>> have to do Math.min(a, Math(min(b, c)) or some such. >> >> >> I certainly see your point, but I would dare to say that most >> applications rely on the streams much more than SequenceInputStream and >> Math classes, and their lookalikes. Stream.concat is primarily a way to >> merge a few datasource outputs into one, for later uniform processing, >> which, in the nutshell, is one of the most common tasks in data-centric >> applications. Of course, not every such use case has characteristics that >> incline developers to use Stream.concat, such as combination of Stream.of >> and Collection.stream() sources, and even if they do, not every case that >> fits previous requirement requires to merge more than 2 sources. However, >> for mid-to-large scale apps, for which java is known the most, I would say >> it's fairly common. I went over our codebase and found that there were at >> least 10+ usages of concat, and a few of them followed this kinda ugly >> pattern of nested concates. >> >> Separately, it's not just one method. Consider that `concat` is also >>> implemented in specialized streams such as IntStream, DoubleStream, and >>> LongStream. >> >> >> This is unfortunate, but I would dare to say that once Reference >> spliterrator is implemented, others may also be derived by analogy fairly >> quickly >> >> And last but not least, answering Daniel >> >> Not immediately obvious but you can create a Stream> using >>> Stream.of and reduce that using Stream::concat to obtain a Stream. >> >> Something along those lines: >> >> ``` >>> var stream = Stream.of(Stream.of(1,2,3), Stream.of(4), Stream.of(5, 6, >>> 7, 8)).reduce(Stream.empty(), Stream::concat, Stream::concat); >> >> >> This is what I meant by "reduction-like" implementation, which is fairly >> straightforward, but just from the looks of it, one could assume that this >> solution will surely have performance consequences, even if using flatmap >> insead of reduce. Not sure though, how often people would want to use such >> approach on the array of streams huge enough for the performance difference >> to be noticable, though I would assume that there is a non-linear scale of >> consumed time and resources from the length of streams array due to the >> implementation of concat method. >> >> Nevertheless, this is an acceptable workaround for such cases, even >> though not the most readable one. Even if this approach is accepted as >> sufficient for such cases of n-sized array of streams merging, It would >> probably make some sense to put note about it in the docs of the concat >> method. Though, not having concat(Stream..) overload would still remain >> unintuitive for many developers, including me >> >> Thanks everybody for the answers again >> >> Best regards >> >> On Wed, Sep 17, 2025 at 5:15?PM Pavel Rappo >> wrote: >> >>> > this would be a great quality of life improvement >>> >>> Is it such a useful use case, though? I mean, it's no different from >>> SequenceInputStream(...) or Math.min/max for that matter. I very >>> rarely have to do Math.min(a, Math(min(b, c)) or some such. And those >>> methods predate streams API by more than a decade. >>> >>> Separately, it's not just one method. Consider that `concat` is also >>> implemented in specialized streams such as IntStream, DoubleStream, >>> and LongStream. >>> >>> On Wed, Sep 17, 2025 at 2:58?PM Olexandr Rotan >>> wrote: >>> > >>> > Greetings to everyone on the list. >>> > >>> > When working on some routine tasks recently, I have encountered a, >>> seemingly to me, strange decision in design of Stream.concat method, >>> specifically the fact that it accepts exactly two streams. My concrete >>> example was something along the lines of >>> > >>> > var studentIds = ...; >>> > var teacherIds = ...; >>> > var partnerIds = ...; >>> > >>> > return Stream.concat( >>> > studentIds.stream(), >>> > teacherIds.stream(), >>> > partnerIds.stream() // oops, this one doesn't work >>> > ) >>> > >>> > so I had to transform concat to a rather ugly >>> > Stream.concat( >>> > studentIds.stream(), >>> > Stream.concat( >>> > teacherIds.stream(), >>> > partnerIds.stream() >>> > ) >>> > ) >>> > >>> > Later on I had to add 4th stream of a single element (Stream.of), and >>> this one became even more ugly >>> > >>> > When I first wrote third argument to concat and saw that IDE >>> highlights it as error, I was very surprised. This design seems >>> inconsistent not only with the whole java stdlib, but even with Stream.of >>> static method of the same class. Is there any particular reason why concat >>> takes exactly to arguments? >>> > >>> > I would say that, even if just in a form of sugar method that just >>> does reduce on array (varagrs) of streams, this would be a great quality of >>> life improvement, but I'm sure there also may be some room for performance >>> improvement. >>> > >>> > Of course, there are workarounds like Stream.of + flatmap, but: >>> > >>> > 1. It gets messy when trying to concat streams of literal elements set >>> (Stream.of) and streams of collections or arrays >>> > 2. It certainly has significant performance overhead >>> > 3. It still doesn't explain absence of varagrs overload of concat >>> > >>> > So, once again, is there any particular reason to restrict arguments >>> list to exactly two streams? If not, I would be happy to contribute >>> Stream.concat(Stream... streams) overload. >>> > >>> > Best regards >>> > >>> > >>> > >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5281 bytes Desc: S/MIME Cryptographic Signature URL: From darcy at openjdk.org Wed Sep 17 20:50:21 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 17 Sep 2025 20:50:21 GMT Subject: Integrated: 8367787: Expand use of representation equivalence terminology in Float16 In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 20:33:00 GMT, Joe Darcy wrote: > Analogous to recent updates made in Float and Double, along with a double -> Float16 typo fix. This pull request has now been integrated. Changeset: 919f5faa Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/919f5faa4618473eddab39d65fe7c1cc732600b7 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod 8367787: Expand use of representation equivalence terminology in Float16 Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk/pull/27322 From bpb at openjdk.org Wed Sep 17 21:01:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Sep 2025 21:01:15 GMT Subject: RFR: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:02:23 GMT, Naoto Sato wrote: > > Alternatively, maybe we should just check into the exceptions in the src tree and avoid this. @naotoj @bplb, can you provide some opinion on this? > > I agree. Since those exceptions are not likely to change, It would be easier to maintain just to check-in those generated sources into the repository. I concur. Given that the only change since JDK 8 is this 59c59 < * put or compact is invoked upon a read-only buffer." \ --- > * put or compact is invoked upon a read-only buffer." \ these are pretty stable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27338#issuecomment-3304544038 From jlu at openjdk.org Wed Sep 17 22:45:02 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 17 Sep 2025 22:45:02 GMT Subject: RFR: 8367901: Calendar.roll(hour, 24) returns wrong result Message-ID: Please review this PR which addresses an edge case for `GregorianCalendar.roll(int, int)` when the rolled amount would cause the hour to remain the same as before the call. After this change, the expected hour is returned. That is, rolling a full cycle for HOUR (12 hours) and HOUR_OF_DAY (24 hours) should keep the hour the same as before the call. For example, a calendar with HOUR_OF_DAY == 15, cal.roll(Calendar.HOUR_OF_DAY, 23); cal.get(Calendar.HOUR_OF_DAY); // returns 14 cal.roll(Calendar.HOUR_OF_DAY, 24); // Incorrectly returns 16. A full cycle is expected to return the starting hour (15) cal.get(Calendar.HOUR_OF_DAY); cal.roll(Calendar.HOUR_OF_DAY, 25); cal.get(Calendar.HOUR_OF_DAY); // returns 16 ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/27355/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27355&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367901 Stats: 92 lines in 2 files changed: 89 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27355/head:pull/27355 PR: https://git.openjdk.org/jdk/pull/27355 From bpb at openjdk.org Wed Sep 17 23:18:33 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Sep 2025 23:18:33 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 00:32:37 GMT, Brian Burkhalter wrote: >> `File.getCanonicalPath` invokes `GetFinalPathNameByHandle` on the result of `canonicalize0` which causes the drive letter of a mapped drive to be converted to a UNC prefix. If such a substitution is detected, this request proposes to revert the conversion of drive letter to UNC prefix before returning the canonical path. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8355342: Corrected a comment >> Would it be possible to provide a summary as to why we don't run into this with toRealPath? > In `toRealPath`, the function `GetFinalPathNameByHandle` is not invoked unless links are being followed and a reparse point is encountered. In this scenario Directory of Z:\ 09/17/2025 03:39 PM

. 09/17/2025 08:36 AM link [target.txt] 09/10/2025 04:41 PM 18 target.txt where `Z:` is mapped as `net use Z: \\localhost\c$\Temp`, in other words to `C:\Temp`, a similar problem happens with `toRealPath`: jshell> Path.of("Z:\\target.txt").toRealPath() $7 ==> Z:\target.txt jshell> Path.of("Z:\\link").toRealPath() $8 ==> \\localhost\c$\Temp\target.txt ------------- PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3304816136 From swen at openjdk.org Thu Sep 18 01:33:38 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 18 Sep 2025 01:33:38 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <5Fj-3sskuVrYGeq7O-p-fDqM0leju7-PI1tvAUmJzvk=.5051c26e-a43d-4d7f-83b1-5fe30e1031ac@github.com> Message-ID: On Mon, 15 Sep 2025 09:02:11 GMT, Per Minborg wrote: >> We have, for long, established that changes like this should be discussed before putting forward any code. Yet, I am unable to find any discussion in the appropriate mailing list. Please send me the link to the mailing list discussion. I must have missed it for some reason. > >> @minborg >> >> The process went like this: >> >> On August 23rd, I posted an email to the core-libs-dev mailing list titled "Introduce and utilize DecimalDigits.appendPair for efficient two-digit formatting." The message included a link to the pull request (PR) #26911. At the time, the PR was in draft status. >> >> On August 26th, @jodastephen commented on the PR. >> >> He's an expert in java.time, and based on his comments, I created an issue and changed the PR status to RFR. > > This mail appears to merely point out that there is a PR with code. I am unable to locate any discussion *prior* to any code being presented. E.g., whether we should do this or not. What are the pros and cons, etc. What did I miss? > > @minborg > > The process went like this: > > On August 23rd, I posted an email to the core-libs-dev mailing list titled "Introduce and utilize DecimalDigits.appendPair for efficient two-digit formatting." The message included a link to the pull request (PR) #26911. At the time, the PR was in draft status. > > On August 26th, @jodastephen commented on the PR. > > He's an expert in java.time, and based on his comments, I created an issue and changed the PR status to RFR. > > This mail appears to merely point out that there is a PR with code. I am unable to locate any discussion _prior_ to any code being presented. E.g., whether we should do this or not. What are the pros and cons, etc. What did I miss? I think that discussing via email + draft Pull Request will better describe the changes and their effects than just email. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3305066592 From swen at openjdk.org Thu Sep 18 01:33:39 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 18 Sep 2025 01:33:39 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Mon, 15 Sep 2025 13:53:23 GMT, Weijun Wang wrote: > I'd rather see a real public API even if it looks like `StringBuilder::appendInteger(boolean alwaysSign, boolean packWithZero, int minWidth, int number)`. Methods like appendPair are provided for better performance, and you suggest that it is not easy to achieve the same performance with such an API. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3305071018 From darcy at openjdk.org Thu Sep 18 03:39:13 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 18 Sep 2025 03:39:13 GMT Subject: RFR: 8367942: Add API note discussing Double.compareTo total order and IEEE 754 total order Message-ID: Add a total that the total order used by {Double, Float}.compareTo is different than the total order defined by IEEE 754, starting the 2008 version of that standard. ------------- Commit messages: - JDK-8367942: Add API note discussing Double.compareTo total order and IEEE 754 total order Changes: https://git.openjdk.org/jdk/pull/27356/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27356&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367942 Stats: 20 lines in 3 files changed: 19 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27356.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27356/head:pull/27356 PR: https://git.openjdk.org/jdk/pull/27356 From liach at openjdk.org Thu Sep 18 04:47:38 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Sep 2025 04:47:38 GMT Subject: RFR: 8367942: Add API note discussing Double.compareTo total order and IEEE 754 total order In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 03:31:30 GMT, Joe Darcy wrote: > Add a total that the total order used by {Double, Float}.compareTo is different than the total order defined by IEEE 754, starting the 2008 version of that standard. src/java.base/share/classes/java/lang/Double.java line 1443: > 1441: * that is NaN representations whose sign bit is set, to be less > 1442: * than any finite or infinite value, including negative > 1443: * infinity. Also in the IEEE 754 ordering, "positive" NaN values This last sentence seems redundant because the behavior for positive NaN values are the same for both total orders. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27356#discussion_r2357501879 From iwalulya at openjdk.org Thu Sep 18 05:25:46 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 18 Sep 2025 05:25:46 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification LGTM! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3237327044 From cstein at openjdk.org Thu Sep 18 05:54:50 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 18 Sep 2025 05:54:50 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v6] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Fix copyright header [skip ci] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26261/files - new: https://git.openjdk.org/jdk/pull/26261/files/7f2017b4..fd7bf6fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From jpai at openjdk.org Thu Sep 18 05:54:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Sep 2025 05:54:51 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v6] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:52:07 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright header > > [skip ci] The latest changes in `fd7bf6f` look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3237379113 From mbaesken at openjdk.org Thu Sep 18 07:33:09 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 18 Sep 2025 07:33:09 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs Message-ID: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it. ------------- Commit messages: - JDK-8367913 Changes: https://git.openjdk.org/jdk/pull/27358/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27358&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367913 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27358.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27358/head:pull/27358 PR: https://git.openjdk.org/jdk/pull/27358 From geliang at kernel.org Thu Sep 18 07:36:58 2025 From: geliang at kernel.org (Geliang Tang) Date: Thu, 18 Sep 2025 15:36:58 +0800 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> Message-ID: <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> Hi Alan, On Fri, 2025-09-05 at 18:11 +0800, Geliang Tang wrote: > Hi Alan, > > Thanks for your reply. > > On Fri, 2025-09-05 at 10:28 +0100, Alan Bateman wrote: > > ? > > On 05/09/2025 09:43, Geliang Tang wrote: > > ? > > ? > > > ? > > > : > > > > > > 3. Proposed Java API Changes > > > > > > The goal is to allow Java applications to opt-in to using MPTCP > > > when > > > creating sockets, without breaking existing code. The proposed > > > changes > > > are additive and backward-compatible. > > > > > > The core idea is to add a boolean mptcp parameter through the API > > > layers, from the public Socket class down to the native system > > > call. > > > ? > > ? > > ?(moving the discussion to nio-dev and net-dev). > > ? > > ?Adding new constructors to legacy Socket/ServerSocket may work for > > your initial prototype but would be problematic to propose as it > > would bake non-standard features into the standard API. Also many > > high performance servers use SocketChannel rather than Socket. > > ? > > ?One suggestion for a next prototype is to model the enablement of > > MultiPath TCP as as a JDK-specific socket option (see > > jdk.net.ExtendingSocketOptions). All of the standard APIs for > > networking sockets define a setOption method for setting socket > > I was initially concerned that calling setOption() after Socket() > creation to convert TCP to MPTCP was too late. Creating an MPTCP > socket > must be done during the socket() system call. > > > options. If modeled as a socket option then enabling can create a > > new > > AF_INET6/SOCK_STREAM/IPPROTO_MPTCP socket and then dup2 it into > > place > > Until I saw here, it should be feasible if the socket can be created > again and dup when calling setOption(). > > I will try to reimplement MPTCP support using > jdk.net.ExtendingSocketOptions soon and give you feedback. I have completed the implementation. Thanks to Xiang Gao and Gang Yan for their help. I added a new option named TCP_MPTCPIFY in jdk.net.ExtendedSocketOptions (the name was chosen to align with 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option is set, it calls the JNI function mptcpify0. Following your suggestion, mptcpify0 is implemented by referencing Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP socket, uses dup2 to duplicate it, and then closes the redundant socket. I have added your tag in the patch: Suggested-by: Alan Bateman I also included a test example for this option. All modifications can be found here: https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master Please provide any feedback or suggestions. As for the next steps, should I create a new issue for this feature and submit a proper pull request? Thanks, -Geliang > > Thanks, > -Geliang > > > so that the original AF_INET6/SOCK_STREAM/0 socket is closed. > > Enabling can be made to fail if the socket is already bound. It > > could > > copy over existing socket options if needed. Look at the built-in > > (and no longer used) SDP support for an example that does similar > > with AF_INET_SDP/SOCK_STREAM/0. The only API surface would be a > > socket option defined in jdk.net.ExtendingSocketOptions. > > ? > > ?-Alan > > ? > > ? From tschatzl at openjdk.org Thu Sep 18 07:39:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 18 Sep 2025 07:39:27 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 07:38:56 GMT, Fei Yang wrote: >>> @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) >> >> This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. > >> > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) >> >> This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. > > Yes, sure! The purpose is to minimize the difference to avoid possible issues in the future. @RealFYang : going to wait for the response of @theRealAph about the `end->count` matter until early next week, otherwise I'll move this change to cleanups/further enhancements like (JDK-8352069)[https://bugs.openjdk.org/browse/JDK-8352069] already planned. Just want to be "done" at some point with this change :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3305851845 From aph at openjdk.org Thu Sep 18 08:03:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Sep 2025 08:03:17 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3237979731 From aph at openjdk.org Thu Sep 18 08:03:18 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Sep 2025 08:03:18 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> References: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> Message-ID: On Fri, 12 Sep 2025 08:27:01 GMT, Martin Doerr wrote: > Other idea: set count = noreg to prevent usage after it is used under the other name. That wouldn't have solved the aliasing problem, because count and end were being used as aliases for a register in _the same instruction_! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2357941045 From tvaleev at openjdk.org Thu Sep 18 08:50:25 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 18 Sep 2025 08:50:25 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v7] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 21:05:13 GMT, Stuart Marks wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @implSpec > > Intuitively, it feels to me like the invariant `min(a, b) == max(b, a)` would be useful when `a` and `b` compare equal. Still mulling this over.... > > EDIT: never mind. I can't think of a good reason to change the return-first-if-equal rule currently expressed in the spec. The CSR is finally approved, but I need one more review from a Reviewer to merge this change. @stuart-marks probably you can review? Thank you in advance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-3306322771 From alan.bateman at oracle.com Thu Sep 18 11:30:16 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 18 Sep 2025 12:30:16 +0100 Subject: Add Multipath TCP (MPTCP) Support to the Java Networking API In-Reply-To: <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> References: <7403952e-14c1-4ba2-871e-0e2174fd5167@oracle.com> <717920eaaa9d4d0da181d84dd11334dae2568f34.camel@kernel.org> Message-ID: <2b699d6c-d05b-4445-9448-99348eebdf4a@oracle.com> On 18/09/2025 08:36, Geliang Tang wrote: > I have completed the implementation. Thanks to Xiang Gao and Gang Yan > for their help. I added a new option named TCP_MPTCPIFY in > jdk.net.ExtendedSocketOptions (the name was chosen to align with > 'mptcpize' tool in mptcpd and 'mptcpify' in BCC). When this option is > set, it calls the JNI function mptcpify0. > > Following your suggestion, mptcpify0 is implemented by referencing > Java_sun_net_sdp_SdpSupport_convert0. It creates a new MPTCP socket, > uses dup2 to duplicate it, and then closes the redundant socket. > > I have added your tag in the patch: > > Suggested-by: Alan Bateman > > I also included a test example for this option. All modifications can > be found here: > > https://github.com/openjdk/jdk/compare/master...geliangtang:jdk:master > > Please provide any feedback or suggestions. As for the next steps, > should I create a new issue for this feature and submit a proper pull > request? Thanks for confirming that the direction suggested works. This at least demonstrates a feasible direction that does not impact the standard API. As regards next steps then I think start a thread on net-dev to try to get input. I think it would be useful to show potential scenarios where it would be useful and what performance benefits might come from it. I think also useful to talk about whether this is something that an application has to opt into, maybe there are other configuration approaches that would not require application changes? I think it would be useful to discuss testing. If this feature were integrated into the JDK then how would it be tested? Who would test and maintain it? There is a JDK release every 6 months, is someone going test it with each release? If it goes ahead then there the name of the extended socket option and its API docs will need discussion. Details around state will need to be specified, would it be supported to set TCP_MPTCP when bound or connected, does it make sense to ever attempt to set it to false after setting it to true (these are just examples of the details that will need to be specified, they are not important right now). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cstein at openjdk.org Thu Sep 18 12:12:31 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 18 Sep 2025 12:12:31 GMT Subject: Integrated: 8361950: Update to use jtreg 8 In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. This pull request has now been integrated. Changeset: 5db1dfe5 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/5db1dfe5c8b5df40779bb450849e6433aa9825ab Stats: 41 lines in 11 files changed: 9 ins; 19 del; 13 mod 8361950: Update to use jtreg 8 Reviewed-by: jpai, iris, joehw, erikj, ihse, liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/26261 From ghan at openjdk.org Thu Sep 18 12:49:50 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 18 Sep 2025 12:49:50 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string [v2] In-Reply-To: References: Message-ID: > Please review this patch. > > **Description:** > > Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. > > **Test:** > > GHA Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - add regression test - Merge remote-tracking branch 'upstream/master' into 8366421 - Change return type of utfLen to long to prevent overflow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27285/files - new: https://git.openjdk.org/jdk/pull/27285/files/0303a278..bc8d7678 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27285&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27285&range=00-01 Stats: 9593 lines in 224 files changed: 5049 ins; 1184 del; 3360 mod Patch: https://git.openjdk.org/jdk/pull/27285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27285/head:pull/27285 PR: https://git.openjdk.org/jdk/pull/27285 From clanger at openjdk.org Thu Sep 18 12:55:14 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 18 Sep 2025 12:55:14 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> Message-ID: On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it. Code changes look good but I guess somebody from Oracle has to verify this, whether it does not break unwanted things. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3239492738 From ghan at openjdk.org Thu Sep 18 13:02:16 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 18 Sep 2025 13:02:16 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 13:32:01 GMT, Roger Riggs wrote: >> Please review this patch. >> >> **Description:** >> >> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. >> >> **Test:** >> >> GHA > > Can you add a test of the maximum length UTF-8 encoded string. > That would be a string of Integer.MAX_VALUE/2 characters that were > 0xff. > It will likely have to write it to a file and read it back, ByteArrayIn/OutStream wouldn't be big enough. Hi @RogerRiggs @liach Thanks for the suggestion. Creating a string of Integer.MAX_VALUE/2 characters would require enormous memory, even using a file, since the JVM still needs to hold the string content in memory when reading it back. Instead, i used a small string chunk with 1-, 2-, and 3-byte UTF-8 characters and repeatedly called ModifiedUtf.utfLen() in a loop, accumulating the total in a long. This safely simulates a total length exceeding Integer.MAX_VALUE and verifies that the change to long prevents overflow. Could you please take another look when you have time ? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27285#issuecomment-3307322322 From mdoerr at openjdk.org Thu Sep 18 13:03:20 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 18 Sep 2025 13:03:20 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> Message-ID: On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it. +1 ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3239571890 From liach at openjdk.org Thu Sep 18 13:11:30 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Sep 2025 13:11:30 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:59:48 GMT, Guanqiang Han wrote: > This safely simulates a total length exceeding Integer.MAX_VALUE and verifies that the change to long prevents overflow. Can you try derive a **regression** test that fails on mainline and passes with your fix? You can generate a string with `chunk.repeat(iterations)` and run `ModifiedUtf.utfLen` on it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27285#issuecomment-3307366255 From erikj at openjdk.org Thu Sep 18 13:15:40 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 18 Sep 2025 13:15:40 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> Message-ID: <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com> On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it. I have started a verification job with tier1-5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307387278 From mbaesken at openjdk.org Thu Sep 18 13:40:13 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 18 Sep 2025 13:40:13 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com> Message-ID: On Thu, 18 Sep 2025 13:13:20 GMT, Erik Joelsson wrote: > I have started a verification job with tier1-5. Hi Erik, thanks for checking ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307512079 From claes.redestad at oracle.com Thu Sep 18 13:55:11 2025 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Sep 2025 13:55:11 +0000 Subject: Proposal to remove StringConcatFactory#generateMHInlineCopy In-Reply-To: References: Message-ID: <4CB3EF0F-3B1C-416A-9121-634C7062958D@oracle.com> Hi, I think it was https://bugs.openjdk.org/browse/JDK-8336856 which made the old generateMHInline non-default / opt-in. But yes, I?ve planned proposing a removal of this for JDK 26. If you want to file an RFE and work out a PR I?d be happy to approve, otherwise it?s on my to-do list. Thanks! Claes > 17 sep. 2025 kl. 03:13 skrev wenshao : > > With the introduction of 8338930: StringConcatFactory hardCoded string concatenation strategy, the StringConcatFactory#generateMHInlineCopy method is no longer used by default. > > ```java > public final class StringConcatFactory { > private static final int HIGH_ARITY_THRESHOLD; > static { > String highArity = VM.getSavedProperty("java.lang.invoke.StringConcat.highArityThreshold"); > HIGH_ARITY_THRESHOLD = highArity != null ? Integer.parseInt(highArity) : 0; > } > public static CallSite makeConcatWithConstants(MethodHandles.Lookup lookup, > String name, > MethodType concatType, > String recipe, > Object... constants) > throws StringConcatException > { > MethodHandle mh = makeSimpleConcat(concatType, constantStrings); > if (mh == null && concatType.parameterCount() <= HIGH_ARITY_THRESHOLD) { > mh = generateMHInlineCopy(concatType, constantStrings); // no longer used by default. > } > } > } > ``` > > After a year of community use, the InlineHiddenClassStrategy has proven to work well, so I recommend removing the implementation of StringConcatFactory#generateMHInlineCopy. > > - > Shaojin Wen > From rriggs at openjdk.org Thu Sep 18 14:29:40 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Sep 2025 14:29:40 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string [v2] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:49:50 GMT, Guanqiang Han wrote: >> Please review this patch. >> >> **Description:** >> >> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - add regression test > - Merge remote-tracking branch 'upstream/master' into 8366421 > - Change return type of utfLen to long to prevent overflow test/jdk/jdk/internal/util/TestUtfLen.java line 54: > 52: if (total != expected) { > 53: throw new RuntimeException("Expected total=" + expected + " but got " + total); > 54: } This misses the point of testing utfLen; it is always testing the same string testing only the inner path through the code. The PR changes the callers of utfLen and they should be tested, not just the internal function. The test really does need to create the large string and pass it to the APIs that have been changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27285#discussion_r2359593518 From ihse at openjdk.org Thu Sep 18 14:38:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 18 Sep 2025 14:38:19 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> Message-ID: <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com> On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it. make/modules/java.base/Lib.gmk line 165: > 163: LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ > 164: LDFLAGS_aix := -brtl -bexpfull, \ > 165: LIBS_linux := $(LIBDL) $(LIBM), \ I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2359642913 From ihse at openjdk.org Thu Sep 18 14:50:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 18 Sep 2025 14:50:18 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression In-Reply-To: References: Message-ID: On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote: > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Build changes look fine. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25167#pullrequestreview-3240239228 From chen.l.liang at oracle.com Thu Sep 18 15:02:26 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 18 Sep 2025 15:02:26 +0000 Subject: Proposal to remove StringConcatFactory#generateMHInlineCopy In-Reply-To: <4CB3EF0F-3B1C-416A-9121-634C7062958D@oracle.com> References: <4CB3EF0F-3B1C-416A-9121-634C7062958D@oracle.com> Message-ID: I agree with the removal. If we need to restore it, we can always pull it from the git history, or just revert the removal commit. Chen Liang ________________________________ From: core-libs-dev on behalf of Claes Redestad Sent: Thursday, September 18, 2025 8:55 AM To: wenshao Cc: core-libs-dev Subject: Re: Proposal to remove StringConcatFactory#generateMHInlineCopy Hi, I think it was https://bugs.openjdk.org/browse/JDK-8336856 which made the old generateMHInline non-default / opt-in. But yes, I?ve planned proposing a removal of this for JDK 26. If you want to file an RFE and work out a PR I?d be happy to approve, otherwise it?s on my to-do list. Thanks! Claes > 17 sep. 2025 kl. 03:13 skrev wenshao : > > With the introduction of 8338930: StringConcatFactory hardCoded string concatenation strategy, the StringConcatFactory#generateMHInlineCopy method is no longer used by default. > > ```java > public final class StringConcatFactory { > private static final int HIGH_ARITY_THRESHOLD; > static { > String highArity = VM.getSavedProperty("java.lang.invoke.StringConcat.highArityThreshold"); > HIGH_ARITY_THRESHOLD = highArity != null ? Integer.parseInt(highArity) : 0; > } > public static CallSite makeConcatWithConstants(MethodHandles.Lookup lookup, > String name, > MethodType concatType, > String recipe, > Object... constants) > throws StringConcatException > { > MethodHandle mh = makeSimpleConcat(concatType, constantStrings); > if (mh == null && concatType.parameterCount() <= HIGH_ARITY_THRESHOLD) { > mh = generateMHInlineCopy(concatType, constantStrings); // no longer used by default. > } > } > } > ``` > > After a year of community use, the InlineHiddenClassStrategy has proven to work well, so I recommend removing the implementation of StringConcatFactory#generateMHInlineCopy. > > - > Shaojin Wen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihse at openjdk.org Thu Sep 18 15:02:01 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 18 Sep 2025 15:02:01 GMT Subject: RFR: 8367859: Remove nio exception gensrc Message-ID: An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. ------------- Commit messages: - Replace tab with spaces - 8367859: Remove nio exception gensrc Changes: https://git.openjdk.org/jdk/pull/27352/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27352&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367859 Stats: 2055 lines in 39 files changed: 1529 ins; 526 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27352/head:pull/27352 PR: https://git.openjdk.org/jdk/pull/27352 From liach at openjdk.org Thu Sep 18 15:30:54 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Sep 2025 15:30:54 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string [v2] In-Reply-To: References: Message-ID: <2_wgopSyMu_YkO7PjeCF9CKE6RYriseCvp5ujM-NcDo=.34089e76-3bdd-4d84-ba97-5c632a5e943f@github.com> On Thu, 18 Sep 2025 12:49:50 GMT, Guanqiang Han wrote: >> Please review this patch. >> >> **Description:** >> >> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - add regression test > - Merge remote-tracking branch 'upstream/master' into 8366421 > - Change return type of utfLen to long to prevent overflow test/jdk/jdk/internal/util/TestUtfLen.java line 50: > 48: for (int i = 0; i < iterations; i++) { > 49: total += ModifiedUtf.utfLen(chunk, 0); > 50: } Suggestion: long total = ModifiedUtf.utfLen(chunk.repeat(iterations), 0); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27285#discussion_r2359898759 From liach at openjdk.org Thu Sep 18 15:34:54 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Sep 2025 15:34:54 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string [v2] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:49:50 GMT, Guanqiang Han wrote: >> Please review this patch. >> >> **Description:** >> >> Currently, ModifiedUtf.utfLen returns a signed int. For very large strings, this may overflow and produce negative values, leading to incorrect behavior in code that relies on the UTF length. This patch changes the return type to long, which fully resolves the issue and allows safe handling of giant strings. >> >> **Test:** >> >> GHA > > Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - add regression test > - Merge remote-tracking branch 'upstream/master' into 8366421 > - Change return type of utfLen to long to prevent overflow test/jdk/jdk/internal/util/TestUtfLen.java line 34: > 32: import jdk.internal.util.ModifiedUtf; > 33: > 34: public class TestUtfLen { Please rename this to `ModifiedUtfTest`, convert to junit, and turn this into one case for overflow of `utfLen`, like `testUtfLenOverflow`, to align with other tests in the same directory. Core libraries usually use JUnit tests instead of main tests like runtime unless there are sensitive stuff that need flagless or would be perturbed by JUnit or other framework initialization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27285#discussion_r2359918536 From liach at openjdk.org Thu Sep 18 15:40:57 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Sep 2025 15:40:57 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string [v2] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 15:31:50 GMT, Chen Liang wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - add regression test >> - Merge remote-tracking branch 'upstream/master' into 8366421 >> - Change return type of utfLen to long to prevent overflow > > test/jdk/jdk/internal/util/TestUtfLen.java line 34: > >> 32: import jdk.internal.util.ModifiedUtf; >> 33: >> 34: public class TestUtfLen { > > Please rename this to `ModifiedUtfTest`, convert to junit, and turn this into one case for overflow of `utfLen`, like `testUtfLenOverflow`, to align with other tests in the same directory. > > Core libraries usually use JUnit tests instead of main tests like runtime unless there are sensitive stuff that need flagless or would be perturbed by JUnit or other framework initialization. Correction: this test will allocate a 2GB string, so we might still have this test itself as a main and focus on `utfLen` overflow alone, and add something like `@requires os.maxMemory >= 4g` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27285#discussion_r2359950004 From naoto at openjdk.org Thu Sep 18 15:44:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Sep 2025 15:44:54 GMT Subject: RFR: 8367901: Calendar.roll(hour, 24) returns wrong result In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 22:37:52 GMT, Justin Lu wrote: > Please review this PR which addresses an edge case for `GregorianCalendar.roll(int, int)` when the rolled amount would cause the hour to remain the same as before the call. After this change, the expected hour is returned. That is, rolling a full cycle for HOUR (12 hours) and HOUR_OF_DAY (24 hours) should keep the hour the same as before the call. > > For example, a calendar with HOUR_OF_DAY == 15, > > > cal.roll(Calendar.HOUR_OF_DAY, 23); > cal.get(Calendar.HOUR_OF_DAY); // returns 14 > > > cal.roll(Calendar.HOUR_OF_DAY, 24); > // Incorrectly returns 16. A full cycle is expected to return the starting hour (15) > cal.get(Calendar.HOUR_OF_DAY); > > > cal.roll(Calendar.HOUR_OF_DAY, 25); > cal.get(Calendar.HOUR_OF_DAY); // returns 16 Looks good. Left some minor suggestions to the test test/jdk/java/util/Calendar/RollHoursTest.java line 56: > 54: @FieldSource("hours") > 55: void HourOfDayTest(int hour) { > 56: var cal = new GregorianCalendar(2005, 8, 12, PM_HOUR, 30, 45); IIUC, the regression was caused by the fix to [JDK-8152077](https://bugs.openjdk.org/browse/JDK-8152077), where it jiggles an hour on the transition day. So although I don't think it would fail, but it might be helpful to test on one of those days test/jdk/java/util/Calendar/RollHoursTest.java line 59: > 57: // E.g. For hour +50 -> (50 + 15) % 24 = 17 > 58: // For hour -50 -> (24 + (15 - 50) % 24) % 24 > 59: // -> (24 + - 11) % 24 = 13 Not sure "+ -" was intentional, but just wanted to comment. Also this calculation could be a static method, as it is repeated below. ------------- PR Review: https://git.openjdk.org/jdk/pull/27355#pullrequestreview-3240559003 PR Review Comment: https://git.openjdk.org/jdk/pull/27355#discussion_r2359954295 PR Review Comment: https://git.openjdk.org/jdk/pull/27355#discussion_r2359957874 From alanb at openjdk.org Thu Sep 18 16:00:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 16:00:53 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. Can you confirm that tier1 + tier2 are passing? (most of the tests are in tier2). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27352#issuecomment-3308284366 From raffaello.giulietti at oracle.com Thu Sep 18 16:15:14 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Thu, 18 Sep 2025 18:15:14 +0200 Subject: Proposal to remove StringConcatFactory#generateMHInlineCopy In-Reply-To: References: Message-ID: <77f79658-8b01-44f5-8ffb-f05b2f0dcbe5@oracle.com> +1 On 2025-09-17 03:13, wenshao wrote: > With the introduction of 8338930: StringConcatFactory hardCoded string > concatenation strategy, the StringConcatFactory#generateMHInlineCopy > method is no longer used by default. > ...> > After a year of community use, the InlineHiddenClassStrategy has proven > to work well, so I recommend removing the implementation of > StringConcatFactory#generateMHInlineCopy. > > - > Shaojin Wen > From naoto at openjdk.org Thu Sep 18 16:20:33 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Sep 2025 16:20:33 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. charset package changes look good to me src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30: > 28: /** > 29: * Unchecked exception thrown when a string that is not a > 30: * legal charset name is used as such. Could utilize new construct as `{@linkplain Charset##names legal charset name}` ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3240774915 PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360132337 From alanb at openjdk.org Thu Sep 18 16:30:28 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 16:30:28 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:17:24 GMT, Naoto Sato wrote: >> An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. > > src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30: > >> 28: /** >> 29: * Unchecked exception thrown when a string that is not a >> 30: * legal charset name is used as such. > > Could utilize new construct as `{@linkplain Charset##names legal charset name}` I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360178485 From naoto at openjdk.org Thu Sep 18 16:34:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Sep 2025 16:34:55 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:27:50 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/nio/charset/IllegalCharsetNameException.java line 30: >> >>> 28: /** >>> 29: * Unchecked exception thrown when a string that is not a >>> 30: * legal charset name is used as such. >> >> Could utilize new construct as `{@linkplain Charset##names legal charset name}` > > I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize. OK fair enough. I just noticed that the file was modified, ie. // -- This file was mechanically generated: Do not edit! -- // was removed, so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360197251 From alanb at openjdk.org Thu Sep 18 16:35:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 16:35:58 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 23:15:42 GMT, Brian Burkhalter wrote: > where `Z:` is mapped as `net use Z: \\localhost\c$\Temp`, in other words to `C:\Temp`, a similar problem happens with `toRealPath`: > > ``` > jshell> Path.of("Z:\\target.txt").toRealPath() > $7 ==> Z:\target.txt > > jshell> Path.of("Z:\\link").toRealPath() > $8 ==> \\localhost\c$\Temp\target.txt > ``` Are you able to check how it behaves when mapped to a location on different host? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3308451257 From erikj at openjdk.org Thu Sep 18 16:47:16 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 18 Sep 2025 16:47:16 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3240922142 From darcy at openjdk.org Thu Sep 18 16:49:12 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 18 Sep 2025 16:49:12 GMT Subject: RFR: 8367942: Add API note discussing Double.compareTo total order and IEEE 754 total order In-Reply-To: References: Message-ID: <3lKnK7PlzfN4WQ39l6lZTnRpqwhgmf8F_seS1JR4pyo=.002f2184-def7-4b5e-b373-1c02f51c9d49@github.com> On Thu, 18 Sep 2025 04:44:28 GMT, Chen Liang wrote: >> Add a total that the total order used by {Double, Float}.compareTo is different than the total order defined by IEEE 754, starting the 2008 version of that standard. > > src/java.base/share/classes/java/lang/Double.java line 1443: > >> 1441: * that is NaN representations whose sign bit is set, to be less >> 1442: * than any finite or infinite value, including negative >> 1443: * infinity. Also in the IEEE 754 ordering, "positive" NaN values > > This last sentence seems redundant because the behavior for positive NaN values are the same for both total orders. Hmm. Yeah, I wanted to avoid giving too much details on what IEEE 754 does here; they also ascribe ordering between different NaN bit patterns while Double.compareTo puts all NaNs into the same equivalence class. I'll take another run at the text; thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27356#discussion_r2360263378 From alanb at openjdk.org Thu Sep 18 16:54:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Sep 2025 16:54:07 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:32:21 GMT, Naoto Sato wrote: >> I assume Magnus is using the generated classes and I think best to not change anything else with this update. We can follow-up yesterday for "opportunities" to modernize. > > OK fair enough. I just noticed that the file was modified, ie. > > // -- This file was mechanically generated: Do not edit! -- // > > was removed, so. Yes, I think that has to be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360284037 From bpb at openjdk.org Thu Sep 18 17:21:21 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 18 Sep 2025 17:21:21 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: <8OZRZZyc6pyg8QAjOyt-3M_KJ3KF_YwZ-q9SaUmPvvw=.0cf09837-e46c-4da7-8293-a07a82a932f2@github.com> On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. Looks all right. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27352#pullrequestreview-3241093519 From ihse at openjdk.org Thu Sep 18 17:28:26 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 18 Sep 2025 17:28:26 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 16:51:47 GMT, Alan Bateman wrote: >> OK fair enough. I just noticed that the file was modified, ie. >> >> // -- This file was mechanically generated: Do not edit! -- // >> >> was removed, so. > > Yes, I think that has to be removed. Alan is right, I just copied in the generated files. This is the files as generated by my previous PR. See this comment https://github.com/openjdk/jdk/pull/27338#issuecomment-3302348906 for details on how they differ. (Apart from a bug fix it is whitespace and comments only). In addition to this, jcheck complained about the generated files containing tabs, so I also had to replace those with spaces. Please go ahead and modernize the code after this PR. :) (But how to do it "yesterday" eludes me ;-)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27352#discussion_r2360419615 From eirbjo at openjdk.org Thu Sep 18 17:44:44 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 18 Sep 2025 17:44:44 GMT Subject: RFR: 8367942: Add API note discussing Double.compareTo total order and IEEE 754 total order In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 03:31:30 GMT, Joe Darcy wrote: > Add a total that the total order used by {Double, Float}.compareTo is different than the total order defined by IEEE 754, starting the 2008 version of that standard. The leading words of the PR description are not in total order ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27356#issuecomment-3308760735 From djelinski at openjdk.org Thu Sep 18 17:45:17 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 18 Sep 2025 17:45:17 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: <_7u8--cDXCFXH9dBDOIxXrK977Hco0wt1tujbg8diJY=.eac75161-a9a0-4e2c-84e3-aef2489e01c4@github.com> On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3241201475 From jpai at openjdk.org Thu Sep 18 17:45:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Sep 2025 17:45:18 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3241211547 From darcy at openjdk.org Thu Sep 18 17:56:35 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 18 Sep 2025 17:56:35 GMT Subject: RFR: 8367942: Add API note discussing Double.compareTo total order and IEEE 754 total order [v2] In-Reply-To: References: Message-ID: > Add a total that the total order used by {Double, Float}.compareTo is different than the total order defined by IEEE 754, starting the 2008 version of that standard. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27356/files - new: https://git.openjdk.org/jdk/pull/27356/files/d09f54aa..480151ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27356&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27356&range=00-01 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27356.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27356/head:pull/27356 PR: https://git.openjdk.org/jdk/pull/27356 From brian.burkhalter at oracle.com Thu Sep 18 18:08:51 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Sep 2025 18:08:51 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: Message-ID: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> On Sep 17, 2025, at 8:24?AM, Pavel Rappo wrote: FWIW, I too have fallen into this trap, and I did that even more than once. When my brain sees Path.endsWith(String), it somehow silently assumes that its semantic is that of String.endsWith(String). Of course, it isn't. What's worse, I learn about my mistake at runtime. But not because of an exception, no; I learn about it by getting unexpected results. I have filed an issue to improve the specification of this method somehow: https://bugs.openjdk.org/browse/JDK-8368007 There used to be a method that implemented the file extension thingy, but the commit was backed out. If it makes its way back in one form or another, it might help to avoid the trap: One day I might evenutally attempt to push that boulder up the mountain again. Today is not that day. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From openjdk at icemanx.nl Thu Sep 18 18:19:57 2025 From: openjdk at icemanx.nl (Rob Spoor) Date: Thu, 18 Sep 2025 20:19:57 +0200 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> Message-ID: If Path.endsWith(String) and possibly Path.startsWith(String) are deprecated, can we then get Path.endsWithPath(String) and Path.startsWithPath(String) as replacements? Because having to type path.endsWith(path.getFileSystem().getPath(other)) is not only a lot more verbose but my IDE also complains that I don't close the result of calling path.getFileSystem() (which of course I shouldn't), so I have to suppress the warning. On 18/09/2025 20:08, Brian Burkhalter wrote: > > On Sep 17, 2025, at 8:24?AM, Pavel Rappo wrote: > > FWIW, I too have fallen into this trap, and I did that even more than > once. When my brain sees Path.endsWith(String), it somehow silently > assumes that its semantic is that of String.endsWith(String). > > Of course, it isn't. What's worse, I learn about my mistake at > runtime. But not because of an exception, no; I learn about it by > getting unexpected results. > > I have filed an issue to improve the specification of this method somehow: > > https://bugs.openjdk.org/browse/JDK-8368007 > > There used to be a method that implemented the file extension thingy, > but the commit was backed out. If it makes its way back in one form or > another, it might help to avoid the trap: > > One day I might evenutally attempt to push that boulder up the mountain again. Today is not that day. > > Brian From brian.burkhalter at oracle.com Thu Sep 18 18:38:07 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Sep 2025 18:38:07 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> Message-ID: <1DC00AEC-810A-4736-8D5F-D77A68144B58@oracle.com> If Path.endsWith(String) and possibly Path.startsWith(String) were to be deprecated, then perhaps something like Path.{start,end}sWIthString(String) could be replacements? Brian On Sep 18, 2025, at 11:19?AM, Rob Spoor wrote: If Path.endsWith(String) and possibly Path.startsWith(String) are deprecated, can we then get Path.endsWithPath(String) and Path.startsWithPath(String) as replacements? Because having to type path.endsWith(path.getFileSystem().getPath(other)) is not only a lot more verbose but my IDE also complains that I don't close the result of calling path.getFileSystem() (which of course I shouldn't), so I have to suppress the warning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openjdk at icemanx.nl Thu Sep 18 18:51:28 2025 From: openjdk at icemanx.nl (Rob Spoor) Date: Thu, 18 Sep 2025 20:51:28 +0200 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <1DC00AEC-810A-4736-8D5F-D77A68144B58@oracle.com> References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <1DC00AEC-810A-4736-8D5F-D77A68144B58@oracle.com> Message-ID: If I saw a method called endsWithString, I'd be inclined to call path.endsWithString(".html"), which is what started this entire thread. Perhaps both can be added? Path.{start,end}sWithString would default to calling toString().{start,end}sWith(arg) and Path.{start,end}sWithPath would default to calling {start,end}sWith(arg). The latter could default to calling {start,end}sWith(getFileSystem().getPath(arg)) but then custom implementations that do something else (in addition) may not work as expected. On 18/09/2025 20:38, Brian Burkhalter wrote: > If Path.endsWith(String) and possibly Path.startsWith(String) were to be deprecated, then perhaps something like Path.{start,end}sWIthString(String) could be replacements? > > Brian > > On Sep 18, 2025, at 11:19?AM, Rob Spoor wrote: > > If Path.endsWith(String) and possibly Path.startsWith(String) are deprecated, can we then get Path.endsWithPath(String) and Path.startsWithPath(String) as replacements? Because having to type path.endsWith(path.getFileSystem().getPath(other)) is not only a lot more verbose but my IDE also complains that I don't close the result of calling path.getFileSystem() (which of course I shouldn't), so I have to suppress the warning. > From liach at openjdk.org Thu Sep 18 19:23:46 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Sep 2025 19:23:46 GMT Subject: RFR: 8367942: Add API note discussing Double.compareTo total order and IEEE 754 total order [v2] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 17:56:35 GMT, Joe Darcy wrote: >> Add a total that the total order used by {Double, Float}.compareTo is different than the total order defined by IEEE 754, starting the 2008 version of that standard. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. The note looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27356#issuecomment-3309131670 From naoto at openjdk.org Thu Sep 18 20:26:49 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Sep 2025 20:26:49 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v7] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:10:49 GMT, Pavel Rappo wrote: >> Please review this documentation-only change, which I believe does **NOT** require CSR. >> >> The change touches java.time.** classes that I happen to have been using a lot recently. While the diff is pretty self-describing, here's the summary of what I did: >> >> * used a comma separator for some big integer values, to improve readability; >> * fixed a few typos and grammar. >> >> While I'm open to discuss the change, I also have some questions. Note: I'm not attempting to address those questions in this PR. >> >> * What's the significance of the second argument in Duration.between(Temporal, Temporal) being exclusive? For example, would the result of the following call be different if the second argument was inclusive? >> >> Duration.between(Instant.ofEpochSecond(1), Instant.ofEpochSecond(2)) >> >> Are there any cases here where that distinction matters? >> >> * In many cases, the following phrase is used throughout documentation: >> >> > positive or negative >> >> While the intent is clearly to stress the directed nature of values, shouldn't we -- for completeness -- also mention zero where applicable? >> >> * What's the significance of title-case for Java Time-Scale? FWIW, the documentation also uses "Java time-scale". > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Remove CSR-triggering changes Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27296#pullrequestreview-3241974417 From jlu at openjdk.org Thu Sep 18 20:41:58 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 18 Sep 2025 20:41:58 GMT Subject: RFR: 8367901: Calendar.roll(hour, 24) returns wrong result [v2] In-Reply-To: References: Message-ID: > Please review this PR which addresses an edge case for `GregorianCalendar.roll(int, int)` when the rolled amount would cause the hour to remain the same as before the call. After this change, the expected hour is returned. That is, rolling a full cycle for HOUR (12 hours) and HOUR_OF_DAY (24 hours) should keep the hour the same as before the call. > > For example, a calendar with HOUR_OF_DAY == 15, > > > cal.roll(Calendar.HOUR_OF_DAY, 23); > cal.get(Calendar.HOUR_OF_DAY); // returns 14 > > > cal.roll(Calendar.HOUR_OF_DAY, 24); > // Incorrectly returns 16. A full cycle is expected to return the starting hour (15) > cal.get(Calendar.HOUR_OF_DAY); > > > cal.roll(Calendar.HOUR_OF_DAY, 25); > cal.get(Calendar.HOUR_OF_DAY); // returns 16 Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - + - to - in comment - DST test cases + compute expected value as method + improve err msg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27355/files - new: https://git.openjdk.org/jdk/pull/27355/files/f214e1db..9316ca62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27355&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27355&range=00-01 Stats: 81 lines in 1 file changed: 52 ins; 0 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/27355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27355/head:pull/27355 PR: https://git.openjdk.org/jdk/pull/27355 From jlu at openjdk.org Thu Sep 18 20:42:00 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 18 Sep 2025 20:42:00 GMT Subject: RFR: 8367901: Calendar.roll(hour, 24) returns wrong result [v2] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 15:39:25 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with two additional commits since the last revision: >> >> - + - to - in comment >> - DST test cases + compute expected value as method + improve err msg > > test/jdk/java/util/Calendar/RollHoursTest.java line 56: > >> 54: @FieldSource("hours") >> 55: void HourOfDayTest(int hour) { >> 56: var cal = new GregorianCalendar(2005, 8, 12, PM_HOUR, 30, 45); > > IIUC, the regression was caused by the fix to [JDK-8152077](https://bugs.openjdk.org/browse/JDK-8152077), where it jiggles an hour on the transition day. So although I don't think it would fail, but it might be helpful to test on one of those days Good point. Added both _standard -> daylight savings_ and _daylight savings -> standard_ test cases to be thorough, although the former one is the interesting test case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27355#discussion_r2361133554 From prappo at openjdk.org Thu Sep 18 20:55:33 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 18 Sep 2025 20:55:33 GMT Subject: RFR: 8367704: Fix minor documentation issues in java.time.** [v6] In-Reply-To: <_GyFprI68yEvF4sr22xSW-JMBxdH3Ed74lwo8cH3kAA=.17a57e7d-a700-4d1a-9877-0f942345c0aa@github.com> References: <10K0Zn0Pe7aIE41BpKu1yeXhygiOYaNQGoXSh0EhfkA=.df25b6cc-cfef-453d-a2a1-069634a5f65c@github.com> <_GyFprI68yEvF4sr22xSW-JMBxdH3Ed74lwo8cH3kAA=.17a57e7d-a700-4d1a-9877-0f942345c0aa@github.com> Message-ID: On Tue, 16 Sep 2025 23:14:13 GMT, Joe Darcy wrote: >> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: >> >> An empty commit to kick GHA > > Okay -- while some of the changes here are clearly bugs, that doesn't obviate the need for a quick CSR review. > > Regarding _integer_ values, 0 is conventionally neither positive nor negative; it stands alone, hence Math.signum(int): > > "Returns the signum function of the specified int value. (The return value is -1 if the specified value is negative; 0 if the specified value is zero; and 1 if the specified value is positive.)" > > Therefore, "non-negative" integers include zero while "positive" integers do not. @jddarcy, are you okay with me pushing this without CSR? To my mind, it now contains typo fixes and editorial improvements only. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27296#issuecomment-3309694016 From pavel.rappo at gmail.com Thu Sep 18 21:12:31 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Thu, 18 Sep 2025 22:12:31 +0100 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> Message-ID: On Thu, Sep 18, 2025 at 7:08?PM Brian Burkhalter wrote: > I have filed an issue to improve the specification of this method somehow: > > https://bugs.openjdk.org/browse/JDK-8368007 > Personally, a better spec wouldn't have helped me avoid the trap. The spec is already clear. I think it's the combination of the method's name and the argument type that is misleading. I think I learned about this method by scrolling autocompletion suggestions in my IDE. The method seemed to fit my need exactly. Of course, I quickly learned that I was wrong, but somehow kept falling into the same trap. Not sure how representative my experience in this case is, though. Deprecation would flag the method in the IDE and help avoid the trap. But eventually, it would be good to also have the file extension functionality. From jlu at openjdk.org Thu Sep 18 21:35:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 18 Sep 2025 21:35:51 GMT Subject: RFR: 8367703: Unneeded cast in java.text.DigitList.append In-Reply-To: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> References: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> Message-ID: On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote: > During parse routines, DecimalFormat uses DigitList to append digits from the parsed text. > > Note that `digit` is always the int value 0 through 9 (and subsequently the code point 48 through 57) when passed to `append`. > > Currently, `append` accepts a char which forces an int -> char -> byte conversion to be stored in `digits`. This can be simplified to int -> byte if the parameter type for the method is updated. The two call sites can safely make this swap. > > Tiers 1-3 and java.text JCK tests continue to pass with this change. For reference, existing case of casting the result of adding a `char` and `int` to `byte` directly in DigitList when storing in `digits`. https://github.com/openjdk/jdk/pull/27300/files#diff-9950f1f11fffb5ed95549f1067ca7359957b5e8ef89c153d5b1d394edf5df28eL642 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27300#issuecomment-3309790833 From rriggs at openjdk.org Thu Sep 18 21:36:31 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Sep 2025 21:36:31 GMT Subject: [jdk25] RFR: 8367031: [backout] Change java.time month/day field types to 'byte' Message-ID: Propagate [backout] Change java.time month/day field types to 'byte' to jdk 25. Previously reviewed as: https://github.com/openjdk/jdk/pull/27346 ------------- Commit messages: - Backport 0756ecb214b8ab76cb69f354063d153b72f978c2 Changes: https://git.openjdk.org/jdk/pull/27375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27375&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367031 Stats: 17 lines in 4 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27375/head:pull/27375 PR: https://git.openjdk.org/jdk/pull/27375 From rriggs at openjdk.org Thu Sep 18 21:41:07 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Sep 2025 21:41:07 GMT Subject: [jdk25] RFR: 8367031: [backout] Change java.time month/day field types to 'byte' In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 21:25:13 GMT, Roger Riggs wrote: > Propagate [backout] Change java.time month/day field types to 'byte' to jdk 25. > Previously reviewed as: https://github.com/openjdk/jdk/pull/27346 Wrong backport target. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27375#issuecomment-3309801233 From rriggs at openjdk.org Thu Sep 18 21:41:08 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Sep 2025 21:41:08 GMT Subject: [jdk25] Withdrawn: 8367031: [backout] Change java.time month/day field types to 'byte' In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 21:25:13 GMT, Roger Riggs wrote: > Propagate [backout] Change java.time month/day field types to 'byte' to jdk 25. > Previously reviewed as: https://github.com/openjdk/jdk/pull/27346 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27375 From aefimov at openjdk.org Thu Sep 18 21:56:20 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Thu, 18 Sep 2025 21:56:20 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb Marked as reviewed by aefimov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3242208335 From rriggs at openjdk.org Thu Sep 18 22:01:12 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Sep 2025 22:01:12 GMT Subject: RFR: 8367703: Unneeded cast in java.text.DigitList.append In-Reply-To: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> References: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> Message-ID: <7BEF1Gzu4O4GkpsDNj2NEVKp494N5YGj83BsNhfH1Oo=.97af2575-dc73-4083-ae45-e8dba63dd422@github.com> On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote: > During parse routines, DecimalFormat uses DigitList to append digits from the parsed text. > > Note that `digit` is always the int value 0 through 9 (and subsequently the code point 48 through 57) when passed to `append`. > > Currently, `append` accepts a char which forces an int -> char -> byte conversion to be stored in `digits`. This can be simplified to int -> byte if the parameter type for the method is updated. The two call sites can safely make this swap. > > Tiers 1-3 and java.text JCK tests continue to pass with this change. Looks ok. Mostly this is a small change that it is not worthy of a PR. It is just churn in the codebase. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27300#pullrequestreview-3242216681 From swen at openjdk.org Thu Sep 18 22:12:53 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 18 Sep 2025 22:12:53 GMT Subject: RFR: 8368024: Remove StringConcatFactory#generateMHInlineCopy Message-ID: With the introduction of [8336856: Efficient hidden class-based string concatenation strategy](https://github.com/openjdk/jdk/pull/20273) , the StringConcatFactory#generateMHInlineCopy method is no longer used by default. After a year of community use, the InlineHiddenClassStrategy has proven to work well, so I recommend removing the implementation of StringConcatFactory#generateMHInlineCopy. ------------- Commit messages: - clean up StringConcatHelper - remove generateMHInlineCopy Changes: https://git.openjdk.org/jdk/pull/27374/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27374&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368024 Stats: 783 lines in 5 files changed: 1 ins; 780 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27374.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27374/head:pull/27374 PR: https://git.openjdk.org/jdk/pull/27374 From jlu at openjdk.org Thu Sep 18 22:20:29 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 18 Sep 2025 22:20:29 GMT Subject: RFR: 8367703: Unneeded cast in java.text.DigitList.append In-Reply-To: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> References: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> Message-ID: On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote: > During parse routines, DecimalFormat uses DigitList to append digits from the parsed text. > > Note that `digit` is always the int value 0 through 9 (and subsequently the code point 48 through 57) when passed to `append`. > > Currently, `append` accepts a char which forces an int -> char -> byte conversion to be stored in `digits`. This can be simplified to int -> byte if the parameter type for the method is updated. The two call sites can safely make this swap. > > Tiers 1-3 and java.text JCK tests continue to pass with this change. OK, to avoid churn I'll close this PR and include these changes in a future PR in the area. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27300#issuecomment-3309879504 From jlu at openjdk.org Thu Sep 18 22:20:30 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 18 Sep 2025 22:20:30 GMT Subject: Withdrawn: 8367703: Unneeded cast in java.text.DigitList.append In-Reply-To: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> References: <15UI-L234zW8DE6t_5jkhDrViTIGGlsb5dqT5lzkoys=.c2d06cd5-3d11-4c10-bcde-a490b4b218a7@github.com> Message-ID: On Mon, 15 Sep 2025 21:18:12 GMT, Justin Lu wrote: > During parse routines, DecimalFormat uses DigitList to append digits from the parsed text. > > Note that `digit` is always the int value 0 through 9 (and subsequently the code point 48 through 57) when passed to `append`. > > Currently, `append` accepts a char which forces an int -> char -> byte conversion to be stored in `digits`. This can be simplified to int -> byte if the parameter type for the method is updated. The two call sites can safely make this swap. > > Tiers 1-3 and java.text JCK tests continue to pass with this change. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27300 From naoto at openjdk.org Thu Sep 18 22:22:14 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Sep 2025 22:22:14 GMT Subject: RFR: 8367901: Calendar.roll(hour, 24) returns wrong result [v2] In-Reply-To: References: Message-ID: <2UnqBqpjn67XIMoF2UMzHlCKiwx5_Lu81HpVVbe7MOs=.28259db7-2360-4db2-8c18-c9ba2cc817e9@github.com> On Thu, 18 Sep 2025 20:41:58 GMT, Justin Lu wrote: >> Please review this PR which addresses an edge case for `GregorianCalendar.roll(int, int)` when the rolled amount would cause the hour to remain the same as before the call. After this change, the expected hour is returned. That is, rolling a full cycle for HOUR (12 hours) and HOUR_OF_DAY (24 hours) should keep the hour the same as before the call. >> >> For example, a calendar with HOUR_OF_DAY == 15, >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 23); >> cal.get(Calendar.HOUR_OF_DAY); // returns 14 >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 24); >> // Incorrectly returns 16. A full cycle is expected to return the starting hour (15) >> cal.get(Calendar.HOUR_OF_DAY); >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 25); >> cal.get(Calendar.HOUR_OF_DAY); // returns 16 > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - + - to - in comment > - DST test cases + compute expected value as method + improve err msg LGTM test/jdk/java/util/Calendar/RollHoursTest.java line 73: > 71: calendars.get(0).set(2005, 8, 20, 12, 10, 25); > 72: > 73: // Transition to daylight savings time (CST/CDT) --- Nit: I think it is usually called "daylight saving time" ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27355#pullrequestreview-3242247888 PR Review Comment: https://git.openjdk.org/jdk/pull/27355#discussion_r2361302216 From smarks at openjdk.org Thu Sep 18 22:28:07 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 18 Sep 2025 22:28:07 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v7] In-Reply-To: References: Message-ID: On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev wrote: >> 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. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Add @implSpec Overall, looks good, and thanks for persevering through all the nitpicky comments. But the high quality of the result justifies the effort. A couple items of commentary, but nothing actionable. * I note that the `@param` and `@return` clauses end in periods. This isn't the typical javadoc style that I'm familiar with. However, I note that most of the rest of this file is styled this way, so the rule about conforming to the prevailing local style applies. * Although `` is no longer used here, there doesn't seem to be a clear preference about the use of `` vs `` markup in javadoc text. In the `java.base` module the ratio is about 3,000 to 2,000 uses, respectively. The `` markup has a clear but not overwhelming majority. On the other hand, this feels like a 1990s HTML argument, and maybe we just don't care. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25297#pullrequestreview-3242256168 From jlu at openjdk.org Thu Sep 18 22:31:17 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 18 Sep 2025 22:31:17 GMT Subject: RFR: 8367901: Calendar.roll(hour, 24) returns wrong result [v3] In-Reply-To: References: Message-ID: > Please review this PR which addresses an edge case for `GregorianCalendar.roll(int, int)` when the rolled amount would cause the hour to remain the same as before the call. After this change, the expected hour is returned. That is, rolling a full cycle for HOUR (12 hours) and HOUR_OF_DAY (24 hours) should keep the hour the same as before the call. > > For example, a calendar with HOUR_OF_DAY == 15, > > > cal.roll(Calendar.HOUR_OF_DAY, 23); > cal.get(Calendar.HOUR_OF_DAY); // returns 14 > > > cal.roll(Calendar.HOUR_OF_DAY, 24); > // Incorrectly returns 16. A full cycle is expected to return the starting hour (15) > cal.get(Calendar.HOUR_OF_DAY); > > > cal.roll(Calendar.HOUR_OF_DAY, 25); > cal.get(Calendar.HOUR_OF_DAY); // returns 16 Justin Lu has updated the pull request incrementally with one additional commit since the last revision: savings -> saving ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27355/files - new: https://git.openjdk.org/jdk/pull/27355/files/9316ca62..b4a34084 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27355&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27355&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27355/head:pull/27355 PR: https://git.openjdk.org/jdk/pull/27355 From naoto at openjdk.org Thu Sep 18 22:37:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 18 Sep 2025 22:37:20 GMT Subject: RFR: 8367901: Calendar.roll(hour, 24) returns wrong result [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 22:31:17 GMT, Justin Lu wrote: >> Please review this PR which addresses an edge case for `GregorianCalendar.roll(int, int)` when the rolled amount would cause the hour to remain the same as before the call. After this change, the expected hour is returned. That is, rolling a full cycle for HOUR (12 hours) and HOUR_OF_DAY (24 hours) should keep the hour the same as before the call. >> >> For example, a calendar with HOUR_OF_DAY == 15, >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 23); >> cal.get(Calendar.HOUR_OF_DAY); // returns 14 >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 24); >> // Incorrectly returns 16. A full cycle is expected to return the starting hour (15) >> cal.get(Calendar.HOUR_OF_DAY); >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 25); >> cal.get(Calendar.HOUR_OF_DAY); // returns 16 > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > savings -> saving Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27355#pullrequestreview-3242270886 From liach at openjdk.org Thu Sep 18 22:40:07 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Sep 2025 22:40:07 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v7] In-Reply-To: References: Message-ID: On Sun, 3 Aug 2025 13:42:41 GMT, Tagir F. Valeev wrote: >> 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. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Add @implSpec src/java.base/share/classes/java/util/Comparator.java line 201: > 199: * @param o1 an argument. > 200: * @param o2 another argument. > 201: * @param the type of the arguments and the result. Since we are utilizing the least upper bound here, we can probably describe this as: "captures the least upper bound of argument types for the result type" Or should we leave an API note? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2361320277 From asemenyuk at openjdk.org Thu Sep 18 23:01:21 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 18 Sep 2025 23:01:21 GMT Subject: RFR: 8368030: Make package bundlers stateless Message-ID: Introduce `jdk.jpackage.internal.SystemEnvironment` interface to describe system tools needed for building specific package bundles with three immediate subinterfaces: `WinSystemEnvironment`, `LinuxSystemEnvironment`, and `MacDmgSystemEnvironment`. `LinuxSystemEnvironment` has two subinterfaces: `LinuxDebSystemEnvironment` and `LinuxRpmSystemEnvironment`. There is no `MacSystemEnvironment` interface as pkg and dmg bundlers are unrelated, unlike rpm and deb bundlers, which share a fair amount of code. There is no `MacPkgSystemEnvironment` interface because the pkg bundler doesn't validate tools. Instances of these interfaces are created as member fields of the corresponding bundler classes, i.e., bundling system tools are validated only once when a specific bundler is instantiated. ------------- Commit messages: - Remove redundant code - Fix compilation error - Remove redundant ToolValidator.setToolNotFoundErrorHandler() call - Remove redundant "throws IOException" - Allow tool validator not to run validated tool, just check if it exists. Fix tool validator and better test coverage. - New Result class: Option-like type with attached list of exceptions - Split Linux and Windows package bundlers into bundlers and packagers. Created SystemEnvironment interface to hold system properties - paths to build tools. Share a single instance of LinuxSystemEnvironment between BED and RPM bundlers. This is to make `dpkg -s coreutils` command run only once and not twice for each bundler Changes: https://git.openjdk.org/jdk/pull/27377/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27377&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368030 Stats: 3887 lines in 33 files changed: 2331 ins; 1415 del; 141 mod Patch: https://git.openjdk.org/jdk/pull/27377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27377/head:pull/27377 PR: https://git.openjdk.org/jdk/pull/27377 From iris at openjdk.org Thu Sep 18 23:40:52 2025 From: iris at openjdk.org (Iris Clark) Date: Thu, 18 Sep 2025 23:40:52 GMT Subject: RFR: 8367901: Calendar.roll(hour, 24) returns wrong result [v3] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 22:31:17 GMT, Justin Lu wrote: >> Please review this PR which addresses an edge case for `GregorianCalendar.roll(int, int)` when the rolled amount would cause the hour to remain the same as before the call. After this change, the expected hour is returned. That is, rolling a full cycle for HOUR (12 hours) and HOUR_OF_DAY (24 hours) should keep the hour the same as before the call. >> >> For example, a calendar with HOUR_OF_DAY == 15, >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 23); >> cal.get(Calendar.HOUR_OF_DAY); // returns 14 >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 24); >> // Incorrectly returns 16. A full cycle is expected to return the starting hour (15) >> cal.get(Calendar.HOUR_OF_DAY); >> >> >> cal.roll(Calendar.HOUR_OF_DAY, 25); >> cal.get(Calendar.HOUR_OF_DAY); // returns 16 > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > savings -> saving Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27355#pullrequestreview-3242350227 From liach at openjdk.org Fri Sep 19 00:09:14 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 00:09:14 GMT Subject: RFR: 8368050: Validation missing in ClassFile signature factories Message-ID: The Signature modeling in the ClassFile API is missing some validations required by JVMS, notably identifier character restrictions and void type restrictions. In addition, the model currently uses `ClassDesc` to indicate a simple name for an inner class signature, which is incorrect, and this patch proposes to deprecate that API for removal. ------------- Commit messages: - 8368050: Validation missing in ClassFile signature factories Changes: https://git.openjdk.org/jdk/pull/27380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27380&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368050 Stats: 205 lines in 5 files changed: 178 ins; 4 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27380/head:pull/27380 PR: https://git.openjdk.org/jdk/pull/27380 From liach at openjdk.org Fri Sep 19 00:17:49 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 00:17:49 GMT Subject: RFR: 8368050: Validation missing in ClassFile signature factories [v2] In-Reply-To: References: Message-ID: <9dwQW9J2RdNUkmmLuNE634NFUI2T3IoT3AVpk9eEAsY=.3b0b85a5-675b-4982-973d-9e4ed124429b@github.com> > The Signature modeling in the ClassFile API is missing some validations required by JVMS, notably identifier character restrictions and void type restrictions. In addition, the model currently uses `ClassDesc` to indicate a simple name for an inner class signature, which is incorrect, and this patch proposes to deprecate that API for removal. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: More bugs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27380/files - new: https://git.openjdk.org/jdk/pull/27380/files/074c5418..8de7e6df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27380&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27380&range=00-01 Stats: 4 lines in 3 files changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27380/head:pull/27380 PR: https://git.openjdk.org/jdk/pull/27380 From liach at openjdk.org Fri Sep 19 00:27:04 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 00:27:04 GMT Subject: RFR: 8368050: Validation missing in ClassFile signature factories [v3] In-Reply-To: References: Message-ID: <8LlhhpLZIqZV2etxM_LtxLOVSXB0r32mORIq4QLpUEY=.1c11bd62-fd2d-4147-8791-b76ddafe6fa8@github.com> > The Signature modeling in the ClassFile API is missing some validations required by JVMS, notably identifier character restrictions and void type restrictions. In addition, the model currently uses `ClassDesc` to indicate a simple name for an inner class signature, which is incorrect, and this patch proposes to deprecate that API for removal. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix links ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27380/files - new: https://git.openjdk.org/jdk/pull/27380/files/8de7e6df..3acdfe4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27380&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27380&range=01-02 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27380/head:pull/27380 PR: https://git.openjdk.org/jdk/pull/27380 From asemenyuk at openjdk.org Fri Sep 19 00:27:25 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 19 Sep 2025 00:27:25 GMT Subject: RFR: 8368030: Make package bundlers stateless In-Reply-To: References: Message-ID: <6cRTmnUAuzr14sfgHwpHpLWWUtPIkdGNcZAb40DNrj8=.6607d8b8-b18d-454b-bdb7-b6aaccfdfe5f@github.com> On Thu, 18 Sep 2025 22:25:02 GMT, Alexey Semenyuk wrote: > Introduce `jdk.jpackage.internal.SystemEnvironment` interface to describe system tools needed for building specific package bundles with three immediate subinterfaces: `WinSystemEnvironment`, `LinuxSystemEnvironment`, and `MacDmgSystemEnvironment`. > > `LinuxSystemEnvironment` has two subinterfaces: `LinuxDebSystemEnvironment` and `LinuxRpmSystemEnvironment`. > > There is no `MacSystemEnvironment` interface as pkg and dmg bundlers are unrelated, unlike rpm and deb bundlers, which share a fair amount of code. > > There is no `MacPkgSystemEnvironment` interface because the pkg bundler doesn't validate tools. > > Instances of these interfaces are created as member fields of the corresponding bundler classes, i.e., bundling system tools are validated only once when a specific bundler is instantiated. > > Move the bundling code away from *Bundler classes into *Packager classes and completely isolate it from the "params". This is a follow-up for the effort to isolate the "params" in [JDK-8333664](https://bugs.openjdk.org/browse/JDK-8333664). @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/27377#issuecomment-3310083877 From swen at openjdk.org Fri Sep 19 00:40:17 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 19 Sep 2025 00:40:17 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v4] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> <1OaAWvSEovBORemNEvEYnYmj_BFqSKF35XCSRigzXR8=.07d10ace-730c-4bb9-b284-1ee208aa7a99@github.com> Message-ID: On Mon, 15 Sep 2025 03:15:55 GMT, Chen Liang wrote: > This solution, if it is to be accepted, can only be a stopgap measure - I think the most likely feature to replace this hack would be String Templates. What abilities do you think that String Templates should support so that you can cover this use case (when we migrate the DateTimeFormatter to be String template instead of StringBuilder based)? j.t.f.DateTimeFormatterBuilder$CompositePrinterParser supports nesting and Optional, StringTempldate does not support these capabilities. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3310102118 From shaojin.wensj at alibaba-inc.com Fri Sep 19 01:16:37 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Fri, 19 Sep 2025 09:16:37 +0800 Subject: =?UTF-8?B?UHJvcG9zZSB0byBtYWtlIGoudC5mLkRhdGVUaW1lUHJpbnRDb250ZXh0IGltbXV0YWJsZQ==?= Message-ID: I propose to make j.t.f.DateTimePrintContext immutable. Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. In order to make it easier for reviewers to see my ideas, I submitted a draft Pull Request ( https://github.com/openjdk/jdk/pull/26913 ). Please give me feedback. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghan at openjdk.org Fri Sep 19 01:17:51 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 19 Sep 2025 01:17:51 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string [v2] In-Reply-To: <2_wgopSyMu_YkO7PjeCF9CKE6RYriseCvp5ujM-NcDo=.34089e76-3bdd-4d84-ba97-5c632a5e943f@github.com> References: <2_wgopSyMu_YkO7PjeCF9CKE6RYriseCvp5ujM-NcDo=.34089e76-3bdd-4d84-ba97-5c632a5e943f@github.com> Message-ID: On Thu, 18 Sep 2025 15:27:43 GMT, Chen Liang wrote: >> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - add regression test >> - Merge remote-tracking branch 'upstream/master' into 8366421 >> - Change return type of utfLen to long to prevent overflow > > test/jdk/jdk/internal/util/TestUtfLen.java line 50: > >> 48: for (int i = 0; i < iterations; i++) { >> 49: total += ModifiedUtf.utfLen(chunk, 0); >> 50: } > > Suggestion: > > long total = ModifiedUtf.utfLen(chunk.repeat(iterations), 0); String.repeat() cannot generate a string whose total length exceeds Integer.MAX_VALUE due to internal limits. That?s why I used a small chunk and accumulated UTF-8 length in a loop.It seems that the String type cannot hold a string whose length exceeds Integer.MAX_VALUE. https://github.com/openjdk/jdk/blob/e3a4c28409ac62feee9efe069e3a3482e7e2cdd2/src/java.base/share/classes/java/lang/String.java#L4875 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27285#discussion_r2361471514 From iklam at openjdk.org Fri Sep 19 01:38:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 01:38:25 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class - @ashu-mehra review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=07 Stats: 903 lines in 43 files changed: 498 ins; 212 del; 193 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From liach at openjdk.org Fri Sep 19 01:42:27 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 01:42:27 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string [v2] In-Reply-To: References: <2_wgopSyMu_YkO7PjeCF9CKE6RYriseCvp5ujM-NcDo=.34089e76-3bdd-4d84-ba97-5c632a5e943f@github.com> Message-ID: On Fri, 19 Sep 2025 01:15:14 GMT, Guanqiang Han wrote: >> test/jdk/jdk/internal/util/TestUtfLen.java line 50: >> >>> 48: for (int i = 0; i < iterations; i++) { >>> 49: total += ModifiedUtf.utfLen(chunk, 0); >>> 50: } >> >> Suggestion: >> >> long total = ModifiedUtf.utfLen(chunk.repeat(iterations), 0); > > String.repeat() cannot generate a string whose total length exceeds Integer.MAX_VALUE due to internal limits. That?s why I used a small chunk and accumulated UTF-8 length in a loop.It seems that the String type cannot hold a string whose length exceeds Integer.MAX_VALUE. > https://github.com/openjdk/jdk/blob/e3a4c28409ac62feee9efe069e3a3482e7e2cdd2/src/java.base/share/classes/java/lang/String.java#L4875 jshell --add-exports java.base/jdk.internal.util=ALL-UNNAMED | Welcome to JShell -- Version 24 | For an introduction type: /help intro jshell> import jdk.internal.util.ModifiedUtf; jshell> var s = "\u0100\u0100\u2600".repeat(Integer.MAX_VALUE / 6 - 1); s ==> "???????????????????????????????????????????????? ... ?????????????????????????" jshell> ModifiedUtf.utfLen(s) | Error: | method utfLen in class jdk.internal.util.ModifiedUtf cannot be applied to given types; | required: java.lang.String,int | found: java.lang.String | reason: actual and formal argument lists differ in length | ModifiedUtf.utfLen(s) | ^----------------^ jshell> ModifiedUtf.utfLen(s, 0) $3 ==> -1789569716 You can construct such a string if the number of bytes in the Modified UTF 8 form is more than the number of bytes in UTF16 form, such as if you use all 3-byte characters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27285#discussion_r2361493886 From swen at openjdk.org Fri Sep 19 01:43:31 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 19 Sep 2025 01:43:31 GMT Subject: RFR: 8366224: Introduce DecimalDigits.appendPair for efficient two-digit formatting and refactor DateTimeHelper [v5] In-Reply-To: References: <7wu_pNErSDMjpckg7l4hL1juFBabftkPPapHr9TIZy8=.88b9d667-45c3-4f8f-9ed7-48393915855a@github.com> Message-ID: On Mon, 15 Sep 2025 06:11:18 GMT, Shaojin Wen wrote: >> This PR introduces a new efficient API for appending two-digit integers to StringBuilders and refactors DateTimeHelper to leverage this new functionality. >> >> Changes include: >> >> 1. New `appendPair` method for efficient two-digit integer formatting (00-99): >> - Added `AbstractStringBuilder.appendPair(int i)` with core implementation >> - Added `JavaLangAccess.appendPair(StringBuilder, int)` for internal access >> - Added `System.JavaLangAccessImpl.appendPair(StringBuilder, int)` bridge >> - Added `DecimalDigits.appendPair(StringBuilder, int)` public static utility method >> - Enhanced Javadoc documentation for all new methods >> >> 2. Refactored `DateTimeHelper` to use the new `DecimalDigits.appendPair`: >> - Updated `DateTimeHelper.formatTo` methods for `LocalDate` and `LocalTime` >> - Replaced manual formatting logic with the new efficient two-digit appending >> - Improved code clarity and consistency in date/time formatting >> >> These changes improve code clarity and performance when formatting two-digit numbers, particularly in date/time formatting scenarios. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/jdk/internal/util/DecimalDigitsTest.java > > Co-authored-by: Chen Liang appendPair is a special implementation that uses DecimalDigits for formatting output of second, minute, hour, dayOfMonth, and month values ??that are >= 0 and less than 100. This eliminates the need to call stringSize or perform the append('0') operation when the value is less than 10, significantly improving performance. The other widths mentioned by @wangweij can be implemented using repeat('0') + append(int) without adding new methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26911#issuecomment-3310192257 From iklam at openjdk.org Fri Sep 19 01:44:26 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 01:44:26 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: References: Message-ID: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> On Fri, 19 Sep 2025 01:38:25 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes > - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class > - @ashu-mehra review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 @ashu-mehra , I've remove all the code that was needed to handle aot-linked classes from the dynamic archive but is no longer needed since [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). I am able to remove about 200 lines of code. I also renamed a few functions in `AOTLinkedClassBulkLoader` to reflect the up-to-date meaning. `CDSConfig::is_using_preloaded_classes()` has been removed and replaced with `CDSConfig::is_using_aot_linked_classes()` The handling of `fixup_mirror_list()` and `fixup_module_field_list()` in javaClasses.cpp have been made uniform. Please see https://github.com/openjdk/jdk/pull/26375/commits/896ce8b9636a5534f1db487afbe27e875022fbfa ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3310193834 From iklam at openjdk.org Fri Sep 19 02:10:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 02:10:15 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v5] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Updated requirements for annotations on supertypes for AOTInitialize and AOTSafeClassInitializer - Merge branch 'master' into aot-initialize-math-utils - Added logging about @AOTSafeClassInitializer classes that have not been initialized - Added comment about the order of FinalImageRecipes::apply_recipes() vs link_all_loaded_classes() - Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." - Added javadoc; added test case; code clean up - Merge branch 'master' into aot-initialize-math-utils - cleanup - Merge branch 'master' into aot-initialize-math-utils - Merge branch '8366477-refactor-aot-related-flag-bits-in-klass-hpp' into aot-initialize-math-utils - ... and 13 more: https://git.openjdk.org/jdk/compare/7ec3fa5f...d21bfb12 ------------- Changes: https://git.openjdk.org/jdk/pull/27024/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=04 Stats: 350 lines in 12 files changed: 288 ins; 54 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From iklam at openjdk.org Fri Sep 19 02:10:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 02:10:16 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 19:08:46 GMT, Ashutosh Mehra wrote: > > Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). > > So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? Yes, that's a bug in the current code in the mainline. > There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: > > https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 I updated the requirements about safety and supertypes for both `AOTInitialize` and `AOTSafeClassInitializer` to use the exact same wording. I think it's OK to describe the effect (the AOT assembly phase will fail) without the details about where we do the checks: /// Before adding this annotation to a class _X_, the author must determine /// that it's safe to execute the static initializer of _X_ during the AOT /// assembly phase. In addition, all supertypes of _X_ must also have this /// annotation. If a supertype of _X_ is found to be missing this annotation, /// the AOT assembly phase will fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3310249049 From iklam at openjdk.org Fri Sep 19 02:14:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 02:14:31 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 19:05:37 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Added logging about @AOTSafeClassInitializer classes that have not been initialized > > src/hotspot/share/cds/aotClassInitializer.cpp line 53: > >> 51: >> 52: if (ik->force_aot_initialization()) { >> 53: assert(ik->is_initialized(), "must have been initialized before this check"); > > Is it not possible for a jdk class to be loaded but not initialized during an application run? If such a jdk class is marked with AOTInitialize annotation, this assert would trigger during the assembly phase. We come to here only in the assembly phase, after this check: if (!CDSConfig::is_initing_classes_at_dump_time()) { return false; } In the training run, `is_initing_classes_at_dump_time()` returns false. Also, in `AOTMetaspace::try_link_class()`, which is called before we enter the CDS safepoint, we try to initialize all `force_aot_initialization()` classes in this loop: https://github.com/openjdk/jdk/blob/d21bfb1231bec75bc6eb6eaac33c95ed833565fb/src/hotspot/share/cds/aotMetaspace.cpp#L1262-L1272 When we come to here, we are already in the CDS safepoint, so all classes with `force_aot_initialization()` must have been initialized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2361539771 From smarks at openjdk.org Fri Sep 19 02:28:57 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 19 Sep 2025 02:28:57 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v7] In-Reply-To: References: Message-ID: <5TJJBuSwHiG4pNBJ-nFFFGUYwdZoZ-LBWdKDbQlbMO4=.918da1ef-0548-4b06-b2c5-c21b85367233@github.com> On Thu, 18 Sep 2025 22:34:52 GMT, Chen Liang wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @implSpec > > src/java.base/share/classes/java/util/Comparator.java line 201: > >> 199: * @param o1 an argument. >> 200: * @param o2 another argument. >> 201: * @param the type of the arguments and the result. > > Since we are utilizing the least upper bound here, we can probably describe this as: > > "captures the least upper bound of argument types for the result type" > > Or should we leave an API note? Most docs for type arguments aren't that specific. I checked a bunch in Collections, Collection, and Class, and they're pretty simple and not precise. For example, in Collection we have: T[] toArray(T[] a) @param the component type of the array to contain the collection Additionally, I'm not sure that `U` is actually the LUB of the types of the arguments. `U`'s upper bound of `T` might require it to be something different. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2361554171 From liach at openjdk.org Fri Sep 19 02:44:43 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 02:44:43 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v7] In-Reply-To: <5TJJBuSwHiG4pNBJ-nFFFGUYwdZoZ-LBWdKDbQlbMO4=.918da1ef-0548-4b06-b2c5-c21b85367233@github.com> References: <5TJJBuSwHiG4pNBJ-nFFFGUYwdZoZ-LBWdKDbQlbMO4=.918da1ef-0548-4b06-b2c5-c21b85367233@github.com> Message-ID: On Fri, 19 Sep 2025 02:25:50 GMT, Stuart Marks wrote: >> src/java.base/share/classes/java/util/Comparator.java line 201: >> >>> 199: * @param o1 an argument. >>> 200: * @param o2 another argument. >>> 201: * @param the type of the arguments and the result. >> >> Since we are utilizing the least upper bound here, we can probably describe this as: >> >> "captures the least upper bound of argument types for the result type" >> >> Or should we leave an API note? > > Most docs for type arguments aren't that specific. I checked a bunch in Collections, Collection, and Class, and they're pretty simple and not precise. For example, in Collection we have: > > T[] toArray(T[] a) > > @param the component type of the array to contain the collection > > Additionally, I'm not sure that `U` is actually the LUB of the types of the arguments. `U`'s upper bound of `T` might require it to be something different. I think we still should describe U as only the type of result - the arguments can be more specific, U is any common supertype of the two argument types but is usually induced by Java language rule to be the lub ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2361583444 From iklam at openjdk.org Fri Sep 19 04:46:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 04:46:13 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed 32-bit builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/04cb7a64..9ec10f5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=07-08 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From dholmes at openjdk.org Fri Sep 19 04:57:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 04:57:19 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:59:48 GMT, Guanqiang Han wrote: > Creating a string of Integer.MAX_VALUE/2 characters would require enormous memory See test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/27285#issuecomment-3310556040 From ghan at openjdk.org Fri Sep 19 05:29:15 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Fri, 19 Sep 2025 05:29:15 GMT Subject: RFR: 8366421: ModifiedUtf.utfLen may overflow for giant string [v2] In-Reply-To: References: <2_wgopSyMu_YkO7PjeCF9CKE6RYriseCvp5ujM-NcDo=.34089e76-3bdd-4d84-ba97-5c632a5e943f@github.com> Message-ID: On Fri, 19 Sep 2025 01:39:52 GMT, Chen Liang wrote: >> String.repeat() cannot generate a string whose total length exceeds Integer.MAX_VALUE due to internal limits. That?s why I used a small chunk and accumulated UTF-8 length in a loop.It seems that the String type cannot hold a string whose length exceeds Integer.MAX_VALUE. >> https://github.com/openjdk/jdk/blob/e3a4c28409ac62feee9efe069e3a3482e7e2cdd2/src/java.base/share/classes/java/lang/String.java#L4875 > > jshell --add-exports java.base/jdk.internal.util=ALL-UNNAMED > | Welcome to JShell -- Version 24 > | For an introduction type: /help intro > > jshell> import jdk.internal.util.ModifiedUtf; > > jshell> var s = "\u0100\u0100\u2600".repeat(Integer.MAX_VALUE / 6 - 1); > s ==> "???????????????????????????????????????????????? ... ?????????????????????????" > > jshell> ModifiedUtf.utfLen(s) > | Error: > | method utfLen in class jdk.internal.util.ModifiedUtf cannot be applied to given types; > | required: java.lang.String,int > | found: java.lang.String > | reason: actual and formal argument lists differ in length > | ModifiedUtf.utfLen(s) > | ^----------------^ > > jshell> ModifiedUtf.utfLen(s, 0) > $3 ==> -1789569716 > > > You can construct such a string if the number of bytes in the Modified UTF 8 form is more than the number of bytes in UTF16 form, such as if you use all 3-byte characters. Got it! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27285#discussion_r2361812961 From chen.l.liang at oracle.com Fri Sep 19 05:48:24 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 19 Sep 2025 05:48:24 +0000 Subject: Propose to make j.t.f.DateTimePrintContext immutable In-Reply-To: References: Message-ID: Hi wenshao, I think this is a very good proposal that makes code much cleaner. This allows us to migrate this context to value classes in the future for better optimization, improves the thread safety of the optional status tracking (compared to throwing exceptions), and makes the context thread safe. Regards, Chen ________________________________ From: core-libs-dev on behalf of wenshao Sent: Thursday, September 18, 2025 8:16 PM To: core-libs-dev Subject: Propose to make j.t.f.DateTimePrintContext immutable I propose to make j.t.f.DateTimePrintContext immutable. Currently, DateTimePrintContext has only one mutable field, optional. This can be replaced by adding an optional parameter to the DateTimeFormatter.formatTo method. Immutable DateTimePrintContext can be optimized by escape analysis, such as immutable object optimization. In order to make it easier for reviewers to see my ideas, I submitted a draft Pull Request ( https://github.com/openjdk/jdk/pull/26913 ). Please give me feedback. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Fri Sep 19 07:06:12 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Sep 2025 07:06:12 GMT Subject: RFR: 8368050: Validation missing in ClassFile signature factories [v3] In-Reply-To: <8LlhhpLZIqZV2etxM_LtxLOVSXB0r32mORIq4QLpUEY=.1c11bd62-fd2d-4147-8791-b76ddafe6fa8@github.com> References: <8LlhhpLZIqZV2etxM_LtxLOVSXB0r32mORIq4QLpUEY=.1c11bd62-fd2d-4147-8791-b76ddafe6fa8@github.com> Message-ID: On Fri, 19 Sep 2025 00:27:04 GMT, Chen Liang wrote: >> The Signature modeling in the ClassFile API is missing some validations required by JVMS, notably identifier character restrictions and void type restrictions. In addition, the model currently uses `ClassDesc` to indicate a simple name for an inner class signature, which is incorrect, and this patch proposes to deprecate that API for removal. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix links src/java.base/share/classes/java/lang/classfile/Signature.java line 246: > 244: * > 245: * @param outerType signature of the outer type, may be {@code null} > 246: * to indicate this is a top-level class or interface Actually here is the ambiguity. Null outer type is more than frequently used also for inner classes. Signatures of inner classes are mainly encoded without the outer type and with the $-notation of the outer$inner as the class name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27380#discussion_r2361989064 From asotona at openjdk.org Fri Sep 19 07:17:19 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Sep 2025 07:17:19 GMT Subject: RFR: 8368050: Validation missing in ClassFile signature factories [v3] In-Reply-To: <8LlhhpLZIqZV2etxM_LtxLOVSXB0r32mORIq4QLpUEY=.1c11bd62-fd2d-4147-8791-b76ddafe6fa8@github.com> References: <8LlhhpLZIqZV2etxM_LtxLOVSXB0r32mORIq4QLpUEY=.1c11bd62-fd2d-4147-8791-b76ddafe6fa8@github.com> Message-ID: <8vnSBrHFT1EWipn5YQGTzZP4wWtFNulrgI586K5frwU=.2c9af32b-2f9d-4795-8eff-29743548d195@github.com> On Fri, 19 Sep 2025 00:27:04 GMT, Chen Liang wrote: >> The Signature modeling in the ClassFile API is missing some validations required by JVMS, notably identifier character restrictions and void type restrictions. In addition, the model currently uses `ClassDesc` to indicate a simple name for an inner class signature, which is incorrect, and this patch proposes to deprecate that API for removal. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix links src/java.base/share/classes/java/lang/classfile/Signature.java line 230: > 228: public static ClassTypeSig of(ClassTypeSig outerType, String className, TypeArg... typeArgs) { > 229: requireNonNull(className); > 230: return new SignaturesImpl.ClassTypeSigImpl(Optional.ofNullable(outerType), className.replace(".", "/"), List.of(typeArgs)); We should declare that the method accepts binary class name only If we remove conversion from binary to internal class name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27380#discussion_r2362009319 From tvaleev at openjdk.org Fri Sep 19 07:19:21 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Fri, 19 Sep 2025 07:19:21 GMT Subject: RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v7] In-Reply-To: References: Message-ID: On Thu, 7 Aug 2025 21:05:13 GMT, Stuart Marks wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @implSpec > > Intuitively, it feels to me like the invariant `min(a, b) == max(b, a)` would be useful when `a` and `b` compare equal. Still mulling this over.... > > EDIT: never mind. I can't think of a good reason to change the return-first-if-equal rule currently expressed in the spec. @stuart-marks thank you for the review! @liach I don't think it's an issue. Yes, it's possible to do the following: void test(Comparator cmp) { String a = "abc"; StringBuilder b = new StringBuilder("abc"); CharSequence max = cmp.max(a, b); // T = Object, U = CharSequence } However, saying that "`CharSequence` is the type of `a` and `b`" is not incorrect. If we have an object of type `String`, it's also an object of type `CharSequence`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25297#issuecomment-3310950943 From tvaleev at openjdk.org Fri Sep 19 07:22:49 2025 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Fri, 19 Sep 2025 07:22:49 GMT Subject: Integrated: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface In-Reply-To: References: Message-ID: On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote: > 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. This pull request has now been integrated. Changeset: 48d394a2 Author: Tagir F. Valeev URL: https://git.openjdk.org/jdk/commit/48d394a245e7d16423b3829efa326fe72605c8ee Stats: 138 lines in 2 files changed: 136 ins; 1 del; 1 mod 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface Reviewed-by: rriggs, smarks ------------- PR: https://git.openjdk.org/jdk/pull/25297 From asotona at openjdk.org Fri Sep 19 07:23:55 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 19 Sep 2025 07:23:55 GMT Subject: RFR: 8368050: Validation missing in ClassFile signature factories [v3] In-Reply-To: <8LlhhpLZIqZV2etxM_LtxLOVSXB0r32mORIq4QLpUEY=.1c11bd62-fd2d-4147-8791-b76ddafe6fa8@github.com> References: <8LlhhpLZIqZV2etxM_LtxLOVSXB0r32mORIq4QLpUEY=.1c11bd62-fd2d-4147-8791-b76ddafe6fa8@github.com> Message-ID: On Fri, 19 Sep 2025 00:27:04 GMT, Chen Liang wrote: >> The Signature modeling in the ClassFile API is missing some validations required by JVMS, notably identifier character restrictions and void type restrictions. In addition, the model currently uses `ClassDesc` to indicate a simple name for an inner class signature, which is incorrect, and this patch proposes to deprecate that API for removal. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix links src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java line 312: > 310: Signature.ClassTypeSig.of( > 311: cts.outerType().map(this::mapSignature).orElse(null), > 312: Util.toInternalName(map(cts.classDesc())), // wrong, needs fix with InnerClasses Signatures of inner classes should be disambiguated to avoid this kind of confusions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27380#discussion_r2362022365 From prr at openjdk.org Fri Sep 19 07:24:51 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 19 Sep 2025 07:24:51 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com> Message-ID: On Thu, 18 Sep 2025 13:37:52 GMT, Matthias Baesken wrote: > I have started a verification job with tier1-5. If that passes, then it is very likely OK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3310536470 From mbaesken at openjdk.org Fri Sep 19 07:24:55 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 19 Sep 2025 07:24:55 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com> Message-ID: On Thu, 18 Sep 2025 14:36:02 GMT, Magnus Ihse Bursie wrote: > I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used. Is there some test for this special functionality? The comments in the C sources https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libsyslookup/syslookup.c do not really help me to understand what functions from libdl we want to bring in this way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2362019646 From mbaesken at openjdk.org Fri Sep 19 07:24:53 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 19 Sep 2025 07:24:53 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> Message-ID: On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it. I can bring back the LIBDL dependency of BUILD_LIBSYSLOOKUP if we are unsure about this single removal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3310964805 From jbhateja at openjdk.org Fri Sep 19 08:23:50 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Sep 2025 08:23:50 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v9] In-Reply-To: References: Message-ID: <-cXUJ-9Nbp1h9REUqjyCpkrlDm4WzeiE0-6mx_QuWs4=.dd56a6a1-a626-4b03-b556-19b2b954a08b@github.com> > This patch optimizes PopCount value transforms using KnownBits information. > Following are the results of the micro-benchmark included with the patch > > > > System: 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark Mode Cnt Score Error Units > PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s > PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s > > Withopt: > Benchmark Mode Cnt Score Error Units > PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s > PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27075/files - new: https://git.openjdk.org/jdk/pull/27075/files/278f1dc8..367622bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27075&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27075&range=07-08 Stats: 33 lines in 1 file changed: 15 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27075/head:pull/27075 PR: https://git.openjdk.org/jdk/pull/27075 From jbhateja at openjdk.org Fri Sep 19 08:23:53 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Sep 2025 08:23:53 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v3] In-Reply-To: <1YTjbiOmc3OUXZlJ_Pg4W6En5hjU0wd_JBHERbVLDWc=.11ddbe0f-685b-463e-87b7-fcdd14ad4bb2@github.com> References: <1YTjbiOmc3OUXZlJ_Pg4W6En5hjU0wd_JBHERbVLDWc=.11ddbe0f-685b-463e-87b7-fcdd14ad4bb2@github.com> Message-ID: <4VQ6YYLFGU3tscZXp3lYhMPDsRvjUlagiJlMe6xiOMc=.20bf3ee6-0822-42f3-8417-1296f5076456@github.com> On Thu, 18 Sep 2025 12:55:16 GMT, Emanuel Peter wrote: >> Hi @TobiHartmann , @SirYwell , @eme64 , can you kindly verify the changes in the latest patch? > > @jatin-bhateja I'm going to be out of the office for about 3 weeks, so feel free to ask others for reviews! Hi @eme64 , @chhagedorn , @SirYwell , let me know if its good to land now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27075#issuecomment-3311136518 From jbhateja at openjdk.org Fri Sep 19 08:23:57 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Sep 2025 08:23:57 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v8] In-Reply-To: References: Message-ID: <_s42gZC5DcP4WobqtuohrzRqET6hpmeaLYwE6BEzcu0=.f24978f2-8ce0-4926-9f5b-0bc2cab57727@github.com> On Tue, 16 Sep 2025 07:15:00 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Extending the random ranges > > test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java line 56: > >> 54: static final long rand_bndL2 = G.uniformLongs(-0xFFFFFFL, 0xFFFFFF).next(); >> 55: static final long rand_popcL1 = G.uniformLongs(0, 4).next(); >> 56: static final long rand_popcL2 = G.uniformLongs(0, 32).next(); > > Can you please give us some code comments why you are doing: > - only uniform distribution. Is that needed? Generators generates special values more often for a good reason: it creates interesting edge cases, especially for bit operations like this here. > - Why are you restricting the ranges? There could always be surprises outside the ranges you pick, and it would be a shame to not generate those. Unless you are absolutely sure they are not needed. Or if extending the range would mean we would generate interesting cases with a probability that is too small, that could be another reason to restrict the ranges. Thanks @eme64!, comment addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2362138729 From ihse at openjdk.org Fri Sep 19 09:11:25 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Sep 2025 09:11:25 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> Message-ID: On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it. I've pinged Maurizio about libsyslookup; let's hear what he says first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3311373364 From ihse at openjdk.org Fri Sep 19 09:11:28 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Sep 2025 09:11:28 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> <5XABPjHsHtv8ByXzgs8cpfV9ZZintNRVCWPawZlq_gU=.ce62a26b-a73b-4829-adfe-1ba31cfaf6af@github.com> Message-ID: <-85YgivfYRWJzsraRo2FEsi432VgfKS5ZrQDn_cjurY=.8409a743-9062-45e9-a598-57a78f0e0dd8@github.com> On Fri, 19 Sep 2025 07:20:11 GMT, Matthias Baesken wrote: >> make/modules/java.base/Lib.gmk line 165: >> >>> 163: LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ >>> 164: LDFLAGS_aix := -brtl -bexpfull, \ >>> 165: LIBS_linux := $(LIBDL) $(LIBM), \ >> >> I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used. > >> I know libsyslookup is special. It is a dummy library that does not really do anything. I wonder if "pulling in libdl" is one of the things it is there for. Iirc, it is not always used either, so you need to make sure you do testing where it is actually used. > > > Is there some test for this special functionality? > > The comments in the C sources > https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libsyslookup/syslookup.c > > do not really help me to understand what functions from libdl we want to bring in this way. @mcimadamore Can you help us here? libsyslookup has a dependency to libdl, but it is not used. Can we remove that from the linker command line, or would it somehow break libsyslookup? (I have just a very fuzzy idea of the point of this library.) If we try to remove it, what tests do we need to run to make sure we do not break anything? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27358#discussion_r2362260334 From epeter at openjdk.org Fri Sep 19 09:41:00 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 19 Sep 2025 09:41:00 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v9] In-Reply-To: <-cXUJ-9Nbp1h9REUqjyCpkrlDm4WzeiE0-6mx_QuWs4=.dd56a6a1-a626-4b03-b556-19b2b954a08b@github.com> References: <-cXUJ-9Nbp1h9REUqjyCpkrlDm4WzeiE0-6mx_QuWs4=.dd56a6a1-a626-4b03-b556-19b2b954a08b@github.com> Message-ID: On Fri, 19 Sep 2025 08:23:50 GMT, Jatin Bhateja wrote: >> This patch optimizes PopCount value transforms using KnownBits information. >> Following are the results of the micro-benchmark included with the patch >> >> >> >> System: 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s >> >> Withopt: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions As I'm about to board my plane for a 3-week vacation, I'm leaving a last little **note for the reviewers**. I think this is a really nice addition, so thanks for doing it @jatin-bhateja ? . Though it will only reach its full potential once we implement more "basic" KnownBits optimizations such as [JDK-8367341](https://bugs.openjdk.org/browse/JDK-8367341). Please make sure you **test** it, and make sure the random values generated with the Generators in `test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java` make sense. Currently, there is for example a 32 bit range for a 64 bit long value, which is not correct, I think. By default, my recommendation is to **not** constrain the Generators ranges, unless there is a really good reason. Generators are already built to produce values close to zero at an over-proportional rate. But by not restricting we may at some point also hit cases that we did not anticipate, and catch bugs that way. test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java line 54: > 52: static final long rand_bndL2 = G.longs().next(); > 53: static final long rand_popcL1 = G.uniformLongs(0, 32).next(); > 54: static final long rand_popcL2 = G.uniformLongs(0, 32).next(); Why did you limit the range for longs to 32? Can it not go up to 64? I asked for an explanation (in a code comment) of those that you restrict here, which you have not done, and just "resolved" it instead: https://github.com/openjdk/jdk/pull/27075#discussion_r2351166568 ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27075#pullrequestreview-3244008016 PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2362301238 From epeter at openjdk.org Fri Sep 19 09:41:04 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 19 Sep 2025 09:41:04 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v9] In-Reply-To: References: <-cXUJ-9Nbp1h9REUqjyCpkrlDm4WzeiE0-6mx_QuWs4=.dd56a6a1-a626-4b03-b556-19b2b954a08b@github.com> Message-ID: On Fri, 19 Sep 2025 09:25:56 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions > > test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java line 54: > >> 52: static final long rand_bndL2 = G.longs().next(); >> 53: static final long rand_popcL1 = G.uniformLongs(0, 32).next(); >> 54: static final long rand_popcL2 = G.uniformLongs(0, 32).next(); > > Why did you limit the range for longs to 32? Can it not go up to 64? > I asked for an explanation (in a code comment) of those that you restrict here, which you have not done, and just "resolved" it instead: > https://github.com/openjdk/jdk/pull/27075#discussion_r2351166568 If you do restrict it, then at least go over the range a little bit. Why? You check `Integer.bitCount(num) < rand_popcI2`. The max value you get here is 32, so we could never get a constant folding case for the range `0..32`. Maybe that is ok, but we potentially miss a chance to find something we did not even anticipate. That is why I would recommend **not** to constrain the values, unless you really have a good reason and write it down in a code comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2362316509 From jbhateja at openjdk.org Fri Sep 19 09:49:16 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Sep 2025 09:49:16 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v10] In-Reply-To: References: Message-ID: > This patch optimizes PopCount value transforms using KnownBits information. > Following are the results of the micro-benchmark included with the patch > > > > System: 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark Mode Cnt Score Error Units > PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s > PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s > > Withopt: > Benchmark Mode Cnt Score Error Units > PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s > PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Update TestPopCountValueTransforms.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27075/files - new: https://git.openjdk.org/jdk/pull/27075/files/367622bf..92cf2fad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27075&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27075&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27075/head:pull/27075 PR: https://git.openjdk.org/jdk/pull/27075 From jbhateja at openjdk.org Fri Sep 19 09:49:18 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Sep 2025 09:49:18 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v9] In-Reply-To: References: <-cXUJ-9Nbp1h9REUqjyCpkrlDm4WzeiE0-6mx_QuWs4=.dd56a6a1-a626-4b03-b556-19b2b954a08b@github.com> Message-ID: On Fri, 19 Sep 2025 09:32:30 GMT, Emanuel Peter wrote: >> test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java line 54: >> >>> 52: static final long rand_bndL2 = G.longs().next(); >>> 53: static final long rand_popcL1 = G.uniformLongs(0, 32).next(); >>> 54: static final long rand_popcL2 = G.uniformLongs(0, 32).next(); >> >> Why did you limit the range for longs to 32? Can it not go up to 64? >> I asked for an explanation (in a code comment) of those that you restrict here, which you have not done, and just "resolved" it instead: >> https://github.com/openjdk/jdk/pull/27075#discussion_r2351166568 > > If you do restrict it, then at least go over the range a little bit. Why? > You check `Integer.bitCount(num) < rand_popcI2`. The max value you get here is 32, so we could never get a constant folding case for the range `0..32`. Maybe that is ok, but we potentially miss a chance to find something we did not even anticipate. > > That is why I would recommend **not** to constrain the values, unless you really have a good reason and write it down in a code comment. > Why did you limit the range for longs to 32? Can it not go up to 64? I asked for an explanation (in a code comment) of those that you restrict here, which you have not done, and just "resolved" it instead: [#27075 (comment)](https://github.com/openjdk/jdk/pull/27075#discussion_r2351166568) A silly typo, so no explanation :-) enjoy your break :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2362345323 From jbhateja at openjdk.org Fri Sep 19 09:53:06 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Sep 2025 09:53:06 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v9] In-Reply-To: References: <-cXUJ-9Nbp1h9REUqjyCpkrlDm4WzeiE0-6mx_QuWs4=.dd56a6a1-a626-4b03-b556-19b2b954a08b@github.com> Message-ID: On Fri, 19 Sep 2025 09:37:45 GMT, Emanuel Peter wrote: > As I'm about to board my plane for a 3-week vacation, I'm leaving a last little **note for the reviewers**. > > I think this is a really nice addition, so thanks for doing it @jatin-bhateja ? . Though it will only reach its full potential once we implement more "basic" KnownBits optimizations such as [JDK-8367341](https://bugs.openjdk.org/browse/JDK-8367341). > Correct, currently KnownBits information is constrained as they are generated for limited value ranges, as discussed in https://github.com/openjdk/jdk/pull/27075#discussion_r2337215333 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27075#issuecomment-3311500441 From ihse at openjdk.org Fri Sep 19 10:05:20 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Sep 2025 10:05:20 GMT Subject: RFR: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: <9Ct4IC_vPNBSZ3ynx8D30co9slKicJkZmoSZGel9WC4=.c965130b-6787-4cd7-94c3-1cb2686e6999@github.com> On Thu, 18 Sep 2025 15:58:07 GMT, Alan Bateman wrote: > Can you confirm that tier1 + tier2 are passing? (most of the tests are in tier2). Yes, they pass with flying colors. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27352#issuecomment-3311543989 From ihse at openjdk.org Fri Sep 19 10:08:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Sep 2025 10:08:18 GMT Subject: Withdrawn: 8367859: Remove shell script from nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:17:33 GMT, Magnus Ihse Bursie wrote: > The only remaining shell script that is being used in the gensrc phase to generate Java code is for the nio exceptions. This should be removed as well, and replaced with a standard solution (Java buildtool or makefile API calls). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27338 From ihse at openjdk.org Fri Sep 19 10:09:39 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 19 Sep 2025 10:09:39 GMT Subject: Integrated: 8367859: Remove nio exception gensrc In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote: > An alternative implementation to https://github.com/openjdk/jdk/pull/27338, which removes the entire gensrc stage and instead permanently checks in the generated Java files. This pull request has now been integrated. Changeset: 65aea485 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/65aea485884134743fbd3da355bd1f861b410704 Stats: 2055 lines in 39 files changed: 1529 ins; 526 del; 0 mod 8367859: Remove nio exception gensrc Reviewed-by: naoto, erikj, bpb ------------- PR: https://git.openjdk.org/jdk/pull/27352 From hgreule at openjdk.org Fri Sep 19 11:19:13 2025 From: hgreule at openjdk.org (Hannes Greule) Date: Fri, 19 Sep 2025 11:19:13 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v10] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 09:49:16 GMT, Jatin Bhateja wrote: >> This patch optimizes PopCount value transforms using KnownBits information. >> Following are the results of the micro-benchmark included with the patch >> >> >> >> System: 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s >> >> Withopt: >> Benchmark Mode Cnt Score Error Units >> PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s >> PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Update TestPopCountValueTransforms.java src/hotspot/share/opto/countbitsnode.cpp line 123: > 121: // we have at least and at most. > 122: // From the definition of KnownBits, we know: > 123: // zeros: Indicates which bits must be 0: ones[i] =1 -> t[i]=0 I'm a bit confused by this, is ones[i] mixed up with zeros[i]? I.e., t[i]=0 if zeros[i]=1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2362569002 From michaelm at openjdk.org Fri Sep 19 11:19:39 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 19 Sep 2025 11:19:39 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v18] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 16:58:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 659 commits: > > - merge latest changes from master branch > - merge latest changes from master branch > - http3: CSR review feedback > - merge latest changes from master branch > - modify http3 test timeouts > - qpack - take knownReceivedCount into account during DT entries eviction > - merge latest changes from master branch > - http3: fix at since > - merge latest http3 changes > - Remove unused variables > - ... and 649 more: https://git.openjdk.org/jdk/compare/9949ee31...5409bdeb I have reviewed the version independent changes only. They look fine to me. ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24751#pullrequestreview-3244405763 From erikj at openjdk.org Fri Sep 19 12:52:38 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 Sep 2025 12:52:38 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com> Message-ID: On Fri, 19 Sep 2025 04:43:29 GMT, Phil Race wrote: > I have started a verification job with tier1-5. Job has completed. There were 2 failures, one had lots of recent history of failing, so seems unrelated. The other was a crash that seemed unusual, but it passed on a rerun. So I think we can say this passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3312072392 From mbaesken at openjdk.org Fri Sep 19 12:52:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 19 Sep 2025 12:52:39 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> <545la8-3hRgR7c9dUVC7OqgxCT8Kcw-nHG7lhXYtCrU=.9ce73e91-7d2a-4669-8286-53caa66c5408@github.com> Message-ID: On Fri, 19 Sep 2025 12:48:03 GMT, Erik Joelsson wrote: > > I have started a verification job with tier1-5. > > Job has completed. There were 2 failures, one had lots of recent history of failing, so seems unrelated. The other was a crash that seemed unusual, but it passed on a rerun. So I think we can say this passed. Thanks for the testing ! So let's wait for some feedback on libsyslookup . ------------- PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3312079386 From liach at openjdk.org Fri Sep 19 13:10:33 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 13:10:33 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v8] In-Reply-To: References: Message-ID: > In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Separate design doc - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate - More review updates - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate - Move intrinsic to be a subsection; just one most common function of the annotation - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java Co-authored-by: Raffaello Giulietti - Shorter first sentence - Updates, thanks to John - ... and 2 more: https://git.openjdk.org/jdk/compare/0d5ea5a0...e4afa49d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24777/files - new: https://git.openjdk.org/jdk/pull/24777/files/a312d92b..e4afa49d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24777&range=06-07 Stats: 348197 lines in 6043 files changed: 206814 ins; 98457 del; 42926 mod Patch: https://git.openjdk.org/jdk/pull/24777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24777/head:pull/24777 PR: https://git.openjdk.org/jdk/pull/24777 From liach at openjdk.org Fri Sep 19 13:10:37 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 13:10:37 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v7] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:31:16 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - More review updates > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Move intrinsic to be a subsection; just one most common function of the annotation > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java > > Co-authored-by: Raffaello Giulietti > - Shorter first sentence > - Updates, thanks to John > - Refine validation and defensive copying > - 8355223: Improve documentation on @IntrinsicCandidate Let's continue. I've moved the majority of check and stuff into a standalone design doc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24777#issuecomment-3312125701 From joehw at openjdk.org Fri Sep 19 16:33:42 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 19 Sep 2025 16:33:42 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v4] In-Reply-To: References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: <4wQG31YN6slC1CFuJ1BF1XSv2L3Z74bDFRNyY17CTaw=.fc79be95-990c-4719-a71a-463248ed52cb@github.com> On Wed, 23 Jul 2025 17:39:12 GMT, Naoto Sato wrote: >> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further wording refinement Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3245786867 From liach at openjdk.org Fri Sep 19 17:02:48 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 17:02:48 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v5] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 02:10:15 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Updated requirements for annotations on supertypes for AOTInitialize and AOTSafeClassInitializer > - Merge branch 'master' into aot-initialize-math-utils > - Added logging about @AOTSafeClassInitializer classes that have not been initialized > - Added comment about the order of FinalImageRecipes::apply_recipes() vs link_all_loaded_classes() > - Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." > - Added javadoc; added test case; code clean up > - Merge branch 'master' into aot-initialize-math-utils > - cleanup > - Merge branch 'master' into aot-initialize-math-utils > - Merge branch '8366477-refactor-aot-related-flag-bits-in-klass-hpp' into aot-initialize-math-utils > - ... and 13 more: https://git.openjdk.org/jdk/compare/7ec3fa5f...d21bfb12 src/hotspot/share/cds/aotMetaspace.cpp line 1266: > 1264: if (HAS_PENDING_EXCEPTION) { > 1265: ResourceMark rm; > 1266: log_error(aot, init)("class %s has @AOTForceInitialize but failed to initialize", Suggestion: log_error(aot, init)("class %s has @AOTInitialize but failed to initialize", ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2363651802 From iklam at openjdk.org Fri Sep 19 17:24:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 17:24:29 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v6] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @liach comment - fixed typo in logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27024/files - new: https://git.openjdk.org/jdk/pull/27024/files/d21bfb12..eecfb42c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From iklam at openjdk.org Fri Sep 19 17:24:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 17:24:32 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v5] In-Reply-To: References: Message-ID: <9sj-YIuj9CGNBwJh06XbAVHS8kq4vAFx23-5i_fOrKY=.e6ebf522-55bf-421c-978e-f4ea987a6016@github.com> On Fri, 19 Sep 2025 16:57:42 GMT, Chen Liang wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Updated requirements for annotations on supertypes for AOTInitialize and AOTSafeClassInitializer >> - Merge branch 'master' into aot-initialize-math-utils >> - Added logging about @AOTSafeClassInitializer classes that have not been initialized >> - Added comment about the order of FinalImageRecipes::apply_recipes() vs link_all_loaded_classes() >> - Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." >> - Added javadoc; added test case; code clean up >> - Merge branch 'master' into aot-initialize-math-utils >> - cleanup >> - Merge branch 'master' into aot-initialize-math-utils >> - Merge branch '8366477-refactor-aot-related-flag-bits-in-klass-hpp' into aot-initialize-math-utils >> - ... and 13 more: https://git.openjdk.org/jdk/compare/7ec3fa5f...d21bfb12 > > src/hotspot/share/cds/aotMetaspace.cpp line 1266: > >> 1264: if (HAS_PENDING_EXCEPTION) { >> 1265: ResourceMark rm; >> 1266: log_error(aot, init)("class %s has @AOTForceInitialize but failed to initialize", > > Suggestion: > > log_error(aot, init)("class %s has @AOTInitialize but failed to initialize", Thanks for catching this. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2363778305 From liach at openjdk.org Fri Sep 19 18:25:31 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 18:25:31 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v6] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 17:24:29 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @liach comment - fixed typo in logging No other comment so far. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27024#pullrequestreview-3246373495 From asmehra at openjdk.org Fri Sep 19 18:41:00 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 18:41:00 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> References: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> Message-ID: On Fri, 19 Sep 2025 01:41:34 GMT, Ioi Lam wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: >> >> - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes >> - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 > > @ashu-mehra , I've remove all the code that was needed to handle aot-linked classes from the dynamic archive but is no longer needed since [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). I am able to remove about 200 lines of code. > > I also renamed a few functions in `AOTLinkedClassBulkLoader` to reflect the up-to-date meaning. > > `CDSConfig::is_using_preloaded_classes()` has been removed and replaced with `CDSConfig::is_using_aot_linked_classes()` > > The handling of `fixup_mirror_list()` and `fixup_module_field_list()` in javaClasses.cpp have been made uniform. > > Please see https://github.com/openjdk/jdk/pull/26375/commits/896ce8b9636a5534f1db487afbe27e875022fbfa @iklam thank you for updating the changes. It is much easier to follow the code now. I have just one additional comment, otherwise looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3313363526 From asmehra at openjdk.org Fri Sep 19 18:41:03 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 18:41:03 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 04:46:13 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed 32-bit builds src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 184: > 182: > 183: void AOTLinkedClassBulkLoader::link_or_init_javabase_classes(TRAPS) { > 184: link_or_init_classes_for_loader(Handle(), AOTLinkedClassTable::get()->boot1(), CHECK); Is exception check not needed here, like it is done in `link_or_init_non_javabase_classes()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2364073186 From aivanov at openjdk.org Fri Sep 19 18:47:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 19 Sep 2025 18:47:38 GMT Subject: RFR: 8367913: LIBDL dependency seems to be not needed for some jdk libs In-Reply-To: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> References: <9oOzAm6lfvY6zqTmqVmOtYrC2Ee8mzAKAhNS-G-jgDA=.1006eb14-10ff-4427-890e-efc6865cdcd4@github.com> Message-ID: On Thu, 18 Sep 2025 07:20:55 GMT, Matthias Baesken wrote: > A couple of JDK native libs link to $(LIBDL) , but some do not use symbols from it. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27358#pullrequestreview-3246478887 From liach at openjdk.org Fri Sep 19 19:29:17 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 19:29:17 GMT Subject: RFR: 8368050: Validation missing in ClassFile signature factories [v4] In-Reply-To: References: Message-ID: > The Signature modeling in the ClassFile API is missing some validations required by JVMS, notably identifier character restrictions and void type restrictions. In addition, the model currently uses `ClassDesc` to indicate a simple name for an inner class signature, which is incorrect, and this patch proposes to deprecate that API for removal. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Fix bad docs and add more to clarify class type sig - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-classtypesig-factory-classdesc - Fix links - More bugs - 8368050: Validation missing in ClassFile signature factories ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27380/files - new: https://git.openjdk.org/jdk/pull/27380/files/3acdfe4a..b21f811e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27380&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27380&range=02-03 Stats: 6010 lines in 136 files changed: 4752 ins; 998 del; 260 mod Patch: https://git.openjdk.org/jdk/pull/27380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27380/head:pull/27380 PR: https://git.openjdk.org/jdk/pull/27380 From vlivanov at openjdk.org Fri Sep 19 19:41:52 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 19 Sep 2025 19:41:52 GMT Subject: RFR: 8290892: C2: Intrinsify Reference.reachabilityFence [v13] In-Reply-To: References: Message-ID: > This PR introduces C2 support for `Reference.reachabilityFence()`. > > After [JDK-8199462](https://bugs.openjdk.org/browse/JDK-8199462) went in, it was discovered that C2 may break the invariant the fix relied upon [1]. So, this is an attempt to introduce proper support for `Reference.reachabilityFence()` in C2. C1 is left intact for now, because there are no signs yet it is affected. > > `Reference.reachabilityFence()` can be used in performance critical code, so the primary goal for C2 is to reduce its runtime overhead as much as possible. The ultimate goal is to ensure liveness information is attached to interfering safepoints, but it takes multiple steps to properly propagate the information through compilation pipeline without negatively affecting generated code quality. > > Also, I don't consider this fix as complete. It does fix the reported problem, but it doesn't provide any strong guarantees yet. In particular, since `ReachabilityFence` is CFG-only node, nothing explicitly forbids memory operations to float past `Reference.reachabilityFence()` and potentially reaching some other safepoints current analysis treats as non-interfering. Representing `ReachabilityFence` as memory barrier (e.g., `MemBarCPUOrder`) would solve the issue, but performance costs are prohibitively high. Alternatively, the optimization proposed in this PR can be improved to conservatively extend referent's live range beyond `ReachabilityFence` nodes associated with it. It would meet performance criteria, but I prefer to implement it as a followup fix. > > Another known issue relates to reachability fences on constant oops. If such constant is GCed (most likely, due to a bug in Java code), similar reachability issues may arise. For now, RFs on constants are treated as no-ops, but there's a diagnostic flag `PreserveReachabilityFencesOnConstants` to keep the fences. I plan to address it separately. > > [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ref/Reference.java#L667 > "HotSpot JVM retains the ref and does not GC it before a call to this method, because the JIT-compilers do not have GC-only safepoints." > > Testing: > - [x] hs-tier1 - hs-tier8 > - [x] hs-tier1 - hs-tier6 w/ -XX:+StressReachabilityFences -XX:+VerifyLoopOptimizations > - [x] java/lang/foreign microbenchmarks Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Remove comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25315/files - new: https://git.openjdk.org/jdk/pull/25315/files/dc37ccad..68150cc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25315&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25315&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25315/head:pull/25315 PR: https://git.openjdk.org/jdk/pull/25315 From rriggs at openjdk.org Fri Sep 19 20:00:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Sep 2025 20:00:55 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v13] In-Reply-To: References: Message-ID: <1eqiNt-YdH-9eeQBzXHohXwfbWxZJaKc8Nis2IiRV-I=.ef506a3b-4456-4d9f-8afc-2ebc7907c6f6@github.com> On Thu, 14 Aug 2025 11:49:15 GMT, Jaikiran Pai wrote: >> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: >> >> update note to @api note > > Hello Kieran, > >> Hi All, Would it be possible to progress review with this? > > I haven't been able to check and respond to your updates, sorry about that. I'll need at least a few more days to come back to this. @jaikiran @rgiulietti Can you give this another look. its been lingering. Tnx. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3313640704 From bpb at openjdk.org Fri Sep 19 20:39:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 19 Sep 2025 20:39:28 GMT Subject: RFR: 8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 20:16:41 GMT, Brian Burkhalter wrote: > [...] post-processing the result from getFinalPath, which I think is a bit too hacky to have in this code. This hack does not work when Z: is mapped to a drive on another machine, at least on my laptop because there is no key HKEY_CURRENT_USER\Network\Z\RemotePath in the registry in this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27324#issuecomment-3313739768 From jbhateja at openjdk.org Fri Sep 19 20:44:54 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Sep 2025 20:44:54 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v11] In-Reply-To: References: Message-ID: > This patch optimizes PopCount value transforms using KnownBits information. > Following are the results of the micro-benchmark included with the patch > > > > System: 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark Mode Cnt Score Error Units > PopCountValueTransform.LogicFoldingKerenLong thrpt 2 215460.670 ops/s > PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 294014.826 ops/s > > Withopt: > Benchmark Mode Cnt Score Error Units > PopCountValueTransform.LogicFoldingKerenLong thrpt 2 389978.082 ops/s > PopCountValueTransform.LogicFoldingKerenlInt thrpt 2 417261.583 ops/s > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Update countbitsnode.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27075/files - new: https://git.openjdk.org/jdk/pull/27075/files/92cf2fad..e206ccc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27075&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27075&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27075/head:pull/27075 PR: https://git.openjdk.org/jdk/pull/27075 From jbhateja at openjdk.org Fri Sep 19 20:52:32 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Sep 2025 20:52:32 GMT Subject: RFR: 8365205: C2: Optimize popcount value computation using knownbits [v10] In-Reply-To: References: Message-ID: <3w_iOULgRgaA1kCHlXrprLPdQfMYcvo1kXqvE7VaaQk=.ab753d0d-1184-4865-bace-564a4938d6d5@github.com> On Fri, 19 Sep 2025 11:16:26 GMT, Hannes Greule wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TestPopCountValueTransforms.java > > src/hotspot/share/opto/countbitsnode.cpp line 123: > >> 121: // we have at least and at most. >> 122: // From the definition of KnownBits, we know: >> 123: // zeros: Indicates which bits must be 0: ones[i] =1 -> t[i]=0 > > I'm a bit confused by this, is ones[i] mixed up with zeros[i]? I.e., t[i]=0 if zeros[i]=1 @SirYwell , comment updated. Links to formal z3 proofs for this:- https://github.com/openjdk/jdk/pull/25928#discussion_r2256750507 https://bugs.openjdk.org/browse/JDK-8365205?focusedId=14807707&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14807707:~:text=C%3A%5CGithub%5Csoftwares%5Cz3%5Cz3%2D4.15.2%2Dx64%2Dwin%5Cbin%5Cpython%3Epython3%20known_bits_popcount.py%0AMain%20constraints%20satisfiable.%0AConstraints%20are%20valid%20(negation%20unsatisfiable). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27075#discussion_r2364498821 From asmehra at openjdk.org Fri Sep 19 21:01:34 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 21:01:34 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 02:05:46 GMT, Ioi Lam wrote: >>> Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). >> >> So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? >> There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 > >> > Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). >> >> So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? > > Yes, that's a bug in the current code in the mainline. > >> There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: >> >> https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 > > I updated the requirements about safety and supertypes for both `AOTInitialize` and `AOTSafeClassInitializer` to use the exact same wording. I think it's OK to describe the effect (the AOT assembly phase will fail) without the details about where we do the checks: > > > /// Before adding this annotation to a class _X_, the author must determine > /// that it's safe to execute the static initializer of _X_ during the AOT > /// assembly phase. In addition, all supertypes of _X_ must also have this > /// annotation. If a supertype of _X_ is found to be missing this annotation, > /// the AOT assembly phase will fail. @iklam Reading up the description of the bug tracker, it seems we are trying to find out more opportunities to AOT initialize classes than the current state. Is that correct? I may be missing something here, why not "force initialize" classes annotated with `AOTSafeClassInitializer` in `AOTMetaspace::try_link_class`, instead of introducing new annotation? Wouldn't that serve the same purpose? And I think we also need to track the classes that are actually initialized in the training phase, and apply "force initialization" only on that subset. Otherwise we can end up in situation where a classes is loaded and not initialized in training phase, but still gets AOT initialized because it is annotated with `AOTInitialize`. > Also, in AOTMetaspace::try_link_class(), which is called before we enter the CDS safepoint, we try to initialize all force_aot_initialization() classes in this loop: @iklam I missed this. It clarifies the situation I was referring to. Thanks for the explanation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3313786069 PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2364513736 From rriggs at openjdk.org Fri Sep 19 21:18:03 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Sep 2025 21:18:03 GMT Subject: RFR: 8364361: [process] java.lang.Process should implement Closeable [v9] In-Reply-To: References: Message-ID: <_Lug1eO2p44t5QFrohyXOyvZPj4lNujnhFYkTKDLcYU=.12cd6fda-9c22-47f9-82d5-0560978827c2@github.com> > The teardown of a Process launched by `ProcessBuilder` includes the closing of streams and ensuring the termination of the process is the responsibility of the caller. The `Process.close()` method provides a clear and obvious way to ensure all the streams are closed and the process terminated. > > The try-with-resources statement is frequently used to open streams and ensure they are closed on exiting the block. By implementing `AutoClosable.close()` the completeness of closing the streams and process termination can be done by try-with-resources. > > The actions of the `close()` method are to close each stream and destroy the process if it has not terminated. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: The CSR review prompted the expansion of the description of responsibilities of subclasses of Process to invoke `super.close()` if overriding the `close()` method. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26649/files - new: https://git.openjdk.org/jdk/pull/26649/files/e35b8fc7..bc795509 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26649&range=07-08 Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26649.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26649/head:pull/26649 PR: https://git.openjdk.org/jdk/pull/26649 From rriggs at openjdk.org Fri Sep 19 21:58:22 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Sep 2025 21:58:22 GMT Subject: RFR: 8355223: Improve documentation on @IntrinsicCandidate [v8] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 13:10:33 GMT, Chen Liang wrote: >> In offline discussion, we noted that the documentation on this annotation does not recommend minimizing the intrinsified section and moving whatever can be done in Java to Java; thus I prepared this documentation update, to shrink a "TLDR" essay to something concise for readers, such as pointing to that list at `vmIntrinsics.hpp` instead of "a list". > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Separate design doc > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - More review updates > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Move intrinsic to be a subsection; just one most common function of the annotation > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/intrinsic-candidate > - Update src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java > > Co-authored-by: Raffaello Giulietti > - Shorter first sentence > - Updates, thanks to John > - ... and 2 more: https://git.openjdk.org/jdk/compare/380c643a...e4afa49d This seems more like guidance for people writing intrinsics and should be in the HotSpot part of the src tree. The annotation can link there. src/java.base/share/classes/jdk/internal/vm/annotation/IntrinsicCandidate.java line 42: > 40: /// what intrinsics are and cautions for working with annotated methods. > 41: /// > 42: /// @since 16 Lets stick to the javadoc /*... */ markup. src/java.base/share/classes/jdk/internal/vm/annotation/intrinsics.md line 1: > 1: