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